
XCMI Job Monitoring TC v5.10                           18 September 2002


--  Module: Job Monitoring TC
--
--
--  File:   40jobtc.dfm, .mib, .pdf, .txt
--  Date:   18 September 2002 - Version 5.11.pub

--
--

                   Definitions of Textual Conventions
                     for Job Monitoring using SMIv2

This document specifies an XCMI (Xerox Common Management Interface)
official standard MIB module for the entire Xerox community, and
requests discussion and suggestions for improvements.  Distribution of
this memo is unlimited within Xerox.  

See section 7, 'Conformance Requirements and Implementers Guide' of the
XCMI Job Monitoring TC for implementation and conformance guidance for
this TC module.  



















XCMI Working Group                 File 40jobtc                 [Page 1]

XCMI Job Monitoring TC v5.10                           18 September 2002



1.  INTRODUCTION

This specification contains the Job Monitoring textual-conventions which
are a companion specification to the Job Monitoring MIB (see files:
41jobmon.dfm, .mib, .pdf, .txt).  This specification also includes the
explanatory information about the Job Monitoring MIB and should be read
first.  It is intended that this specification can be updated and
re-issued as needed with additional enum values and/or explanatory
material, while the Job Monitoring MIB remains with no change, making
the MIB more stable and making it more clear that the textual
conventions can be changed without impacting conformance of
implementations to the MIB.  

The following textual-conventions for enum values are defined:
    XcmJMJobState              Job states from ISO DPA
    XcmJMJobStateReasons       Job state reasons bit encoded
                               but derived from ISO DPA
    XcmJMJobXStateReasons      Job state reason extensions
                               bit encoded for Xerox
    XcmJMJobX2StateReasons     Job state reason extensions number 2
                               bit encoded for Xerox
    XcmJMDocType               Document types from ISO DPA
    XcmJMDocFileNameType       Document file name types from ISO DPA
    XcmJMDocState              Document states from ISO DPA
    XcmJMDocOutputMethod       Document output handling bit encoded
                               but derived from ISO DPA
    XcmJMGroupSupport          JobMon Groups bit encoded for use with
                               the "Support" objects
    XcmJMImpsCountType         Type of how to count impressions
    XcmJMMediumType            Medium type (stationery, transparency,
                               etc.) from ISO DPA medium object.

The following textual-convention for OID values are defined for use in
the Job Monitoring MIB and any ASN.1 protocol that needs them:  
    XcmJMJobServiceTypeOID     Job service type, e.g.,
                               xcmJobServiceScanToFileOID,
                               xcmJobServicePrintOID

The industry standard Job Monitoring MIB [JMP] was adopted by the
Printer Working Group (PWG) at its January 28, 1998 meeting.
Conformance to this XCMI Job Monitoring MIB specification requires that 
SNMP agent projects shall implement either this XCMI Job Monitoring MIB 
specification or the PWG Job Mon MIB, or both.  Agent projects MAY
implement the XCMI Job Mon MIB groups, in addition, if traps and/or the 
XCMI Simple Job Management MIB is needed (since it augments the XCMI Job
Mon MIB).  For the foreseeable future, new SNMP manager projects SHALL
implement both the PWG and the XCMI Job Mon MIBs.  

New Xerox attributes will be registered with the PWG, except for
attributes that Xerox does not want to reveal.  Such attributes, if any,
will continue to be added to the XCMI Job Mon MIB alone.  See the
Implementers Guide section in this specification.  

XCMI Working Group                 File 40jobtc                 [Page 2]

XCMI Job Monitoring TC v5.10                           18 September 2002


Version 3.1 of this MIB specified that many objects and groups were
deprecated, usually in favor of the PWG Job Monitoring MIB.  For various
reasons, Xerox products have not fully embraced the PWG MIB, so almost
all deprecated objects have been undeprecated, starting with version
4.00.  Exceptions are noted as needed.  

















































XCMI Working Group                 File 40jobtc                 [Page 3]

XCMI Job Monitoring TC v5.10                           18 September 2002



2.  OVERVIEW OF THE JOB MONITORING MIB

The Job Monitoring MIB specifies SNMP information object groups for
monitoring general jobs and print jobs.  There are groups for systems
that do not spool job instructions and additional groups for systems
that that do.  Finally, there are groups for systems that include
accounting.  The object groups are arranged so that an additional MIB
may be developed that supports multi-function jobs (print, scan, FAX,
etc.), including scan-only jobs.  Such a MIB is intended to augment the
Job Monitoring MIB.  

The specification for many of the objects in this Job Monitoring MIB is 
taken directly from the ISO 10175 Document Printing Application (DPA)
standard, clause 9.2, Job Attributes and clause 9.3, Document Attributes
(Final text, March 1996).  Multiple documents per job are supported as
an optional feature (as in ISO DPA).  The concept of sub-jobs has been
introduced (not in ISO DPA) as an optional feature, as has
generalization to non-print services.  The full ISO DPA standard is
available via anonymous ftp at ftp-boi.external.hp.com in directory:
/pub/snmpmib/dpa in WORD (.doc) and PostScript(tm) (.ps) forms.  

All direct inclusions of text from ISO DPA are explicitly indicated.
However, this MIB is intended to be used with non-DPA implementations,
so only a small set of general DPA attributes have been included in the 
Job Monitoring MIB.  In addition, a single optional print-centric group 
is included.  Finally, some of the ISO DPA specifications have been
generalized so that they may be used with non-print job services.  For
example, changing the names and descriptions from "printer" to "device".
All such changes to ISO DPA text are indicated inside square brackets to
make it clear how this Job Monitoring MIB differs from ISO DPA.  


2.1.  The Multi-function Job Model

The specification of objects for scan and FAX is just beginning, and
needs agreement on a multi-function (MF) job model first.  

The current thinking on the model for MF jobs is that simple jobs need
to be able to specify a single compound job service instance that the
service provider assigns more than one MF device to the job.  Therefore,
a job needs to specify both scanner and printer attributes.  However,
some of the printer-centric attributes in ISO DPA will be renamed, so
that they may be used with other services.  Also some of the job states 
and other enumerated values have been generalized by re-naming to be
useful for other job services.  For example, instead of the job states
of processing and printing, only the processing state shall be used and 
is re-defined to include printing, scanning, etc., so that the
processing state may be used with other job service types.  The printing
state is DEPRECATED and several values have been added to the
xcmDeviceStateOfDevicesAssigned to give the user the same feedback that 
the processing job is 'interpreting' or 'marking', same as the
DEPRECATED printing state had provided.  However, the entire

XCMI Working Group                 File 40jobtc                 [Page 4]

XCMI Job Monitoring TC v5.10                           18 September 2002

xcmDeviceStateOfDevicesAssigned group has been deprecated, since in some
implementations more than one job can be being processed (interpretted)
by a device at the same time, while only one is actually using the
marker.  Thus the new strategy is to assign job-state-reason bits for
service-specific functions, such as printing, interpreting, scanning,
fax-in, fax-out, etc.  

The model for scan jobs is being worked by the ODP Network Scan
Architecture (NSA) and its job attributes will be used as the basis for 
scan jobs.  The model for out-bound FAX and in-bound FAX needs to be
developed before defining MIB objects.  

For more complex systems, more complex jobs, called compound job,
contain other jobs, called sub-jobs, that perform separate steps of a
multi-function job.  Each such contained sub-job can be separately
scheduled, so that one such sub-job could be a scan job and another
could be a print job.  A compound job could contain multiple source jobs
and multiple destination jobs of different types.  For example, a
compound job could contain a simple scan-to-file job, a file-to-print
job, and a file-to-FAX job.  A very complex compound job might contain
other compound jobs, as well as simple jobs.  

An option for both simple and compound jobs is that a job can contain
multiple (m) documents.  































XCMI Working Group                 File 40jobtc                 [Page 5]

XCMI Job Monitoring TC v5.10                           18 September 2002



3.  GOALS FOR THE JOB MONITORING MIB (HISTORICAL)

The goals for the XCMI Job Monitoring MIB (extracted from the PWG Job
Monitoring MIB work [JMP]) are:  

    1.  Provide a limited set (18) of mandatory job and document
    attributes for a printer, plus 65 or so optional job and document
    attributes, not a complete set of job attributes for a print
    spooling system.  This mandatory subset is intended to be used with
    printer devices that do not include spooling; the optional subset
    may be used with a printer that does include spooling or with a
    spooling system.  
    
    2.  Provide for printers that can contain more than one job at a
    time, but still be usable for low end printers that only contain a
    single job at a time.  In particular, meet the needs of Windows and
    other PC environments for managing low-end networked devices without
    unnecessary overhead or complexity, while also providing for higher
    end printers, devices, and print systems.  Since the Job Monitoring
    MIB will also be transformed into a companion DMTF MIF, the Job
    Monitoring MIB/MIF should meet the needs for managing devices using
    the DMTF DMI when the devices are directly connected to PCs.  
    
    3.  Provide for job information after the printer has finished
    printing the job .  This job information on completed jobs is
    intended to be used by:  
    
        management stations that provide job status to system operators
        that are remote from the printer 
        
        a management station that is co-located with the printer to
        provide an enhanced console capability 
        
        end user job monitoring programs that give end users status on
        progress and completion of jobs during the complete life cycle
        of the job, including for a period after the job completes 
        
        system accounting programs that copy the completed job
        statistics to an accounting system.  Such accounting programs
        can copy the data for implementation on low-end printers that
        cannot rely on the print system to reliably write the accounting
        information when the job completes.  It is recognized that
        depending on accounting programs to copy MIB data during the
        job-retention period in the retained state and/or the completed 
        state is somewhat unreliable, since the accounting program may
        not be running (or may have crashed).  
        
        system usage statistics gathering programs that copy the
        completed job statistics to system usage logs 

    4.  Provide a compatible subset of job and document attributes of
    the ISO DPA standard, so that coherence is maintained between the

XCMI Working Group                 File 40jobtc                 [Page 6]

XCMI Job Monitoring TC v5.10                           18 September 2002

    two protocols and information seen by end users and system
    operators.  However, the Job Monitoring MIB is intended to be used
    with printers and print systems that implemented other job
    submitting and management protocols, such as IEEE 1284.1 (TIPSI), as
    well as with ones that do implement ISO DPA.  So nothing in the Job
    Monitoring MIB requires implementation of the ISO DPA protocol.  
    
    5.  Design this Job Monitoring MIB so that an additional MIB can be 
    specified in the future for monitoring multi-function (scan, FAX,
    copy, and print) jobs.  Design this Job Monitoring MIB so that the
    future multi-function Job Monitoring MIB is able to augment (rather
    than supersede) this MIB.  A subsidiary goal is for this Job
    Monitoring MIB to be designed so that the future multi-function MIB
    can be used with scan systems that do not have a printer.  So
    nothing in the Job Monitoring MIB requires implementation of the
    Printer MIB (RFC 1759), if the device or system does not have a
    printer.  
    
    6.  Solve the security policy problem that unauthorized users cannot
    access job information for jobs that are not theirs.  Solving the
    security problem requires SNMP V2 security.  However, this MIB is
    also intended to be used with SNMP V1 by providing lessor
    conformance requirements when implementing V1.  
    
    7.  Do not provide for additional job management functions, such as 
    ModifyJob, CancelJob, PromoteJob, PauseJob, ResumeJob, InterruptJob.
    If these job management functions are desired, put them into a
    second job management MIB that augments this Job Monitoring MIB.
    Then the conformance to this Job Management MIB is kept distinct
    from the conformance to such a Job Management MIB, since some
    implementations may want to only do the Job Monitoring MIB and
    others may want to implement both.  The ITEF/DMTF Printer Working
    Group (PWG) may wish to develop both MIBs in parallel.  However,
    this document refers only to the Job Monitoring MIB.  
    
    8.  Provide for monitoring of jobs that clients submit (1) directly
    to printers (end user clients or spooling print systems acting as
    clients) and (2) to spooling print systems.  Thus the problem of
    multiple client- server relationships that can exist in some print
    scenarios must be provided for.  Fortunately, the ISO DPA provides
    job attributes for submission and monitoring of such cascaded job
    scenarios.  
    
    9.  Provide an easy way for a management station to access a
    particular job that was submitted by a client without either the
    client or the management station having to maintain a data base.  
    
    Implication:  an id specified by the submitting client is used as
    the index into a client job id to server job id table; the server
    generated job id is used as the job index into the job table.  Since
    multiple clients can submit to a single printer, a unique id for the
    client is pre-pended to the index in the client job id to server job
    id.  Since multiple clients can submit to a single print system or
    printer, the submitting client must provide a unique id with the job

XCMI Working Group                 File 40jobtc                 [Page 7]

XCMI Job Monitoring TC v5.10                           18 September 2002

    submission in order to allow a management station to access the jobs
    without a database.  This unique client id is used as the index in
    the client job id to server job id table.  
    
    10.  Provide SNMP MIB access to jobs submitted to the printer or
    print system by any protocol, including printers and print systems
    that accept jobs using multiple protocols.  


3.1.  Job Management not in the Job Monitoring MIB

This Job Monitoring MIB does not contain job management functions, such 
as cancelling jobs, promoting jobs, etc.  If job management is desired, 
a separate MIB should be developed so that the conformance to that Job
Management MIB would be kept separate from the conformance to this Job
Monitoring MIB.  Then some implementations will implement the Job
Monitoring MIB and others could implement both the Job Monitoring MIB
and the Job Management MIB.  The Job Management MIB would provides
writeable objects that augment the job and document tables in the Job
Monitoring MIB.  Such writeable objects could provide the means to
cancel jobs, cancel documents, promote jobs (to be printed next), etc.  


3.2.  Submission to the Printer Working Group (PWG)

This Job Monitoring MIB was submitted to the Printer Working Group (PWG)
for consideration as a new RFC in September 1995 that may be used with
other RFCs, such as the Printer MIB (RFC 1759).  When we made the
proposal, the Xerox specific nomenclature was changed.  So the MIB
prefix was changed from "xcm" to "jm" for "job monitoring".  If a
separate Job Management or Job Control MIB is also developed by the PWG,
perhaps its prefix could be "jc" for job control.  

Unfortunately, the PWG did not accept the proposal in its entirety.
Instead, the PWG developed a Job Monitoring MIB that was simpler, but
with more attributes, using a flexible four index attribute table.  The 
PWG Job Monitoring MIB does not include traps and does not have
RowStatus.  Also the internationalization is simpler, along the lines of
IPP.  
















XCMI Working Group                 File 40jobtc                 [Page 8]

XCMI Job Monitoring TC v5.10                           18 September 2002



4.  USAGE CONFIGURATIONS OF SYSTEMS OF THE JOB MONITORING MIB

The following usage configurations of printing systems have been agreed 
to by the Printer Working Group (PWG) Job Monitoring Project (JMP) for
usage of the Job Monitoring MIB.  Each configuration show one or more
SNMP Job Monitoring MIB agents accepting SNMP requests for the Job
Monitoring MIB.  The design center for the Job Monitoring MIB will be to
satisfy the needs of agents at the printer and agents on the system
components to which users submit jobs directly.  


4.1.  Configuration 1 - client-printer

In the client-printer configuration, the client(s) submit jobs directly 
to the printer, either by some direct connect, or by network connection.
The client-printer configuration can accommodate multiple job submitting
clients in either of two ways:  
    1.  if each client relinquishes control of the Print Job Delivery
        Channel after each job (or after a number of jobs) 
    2.  if the printer supports more than one Print Job Delivery Channel

The job submitting client and/or monitor communicates directly with an
agent that is either part of the printer or is a front for the printer
using some printer-specific management protocol between the agent and
the printer (for example the management commands in the TIPSI protocol).
Since the means of communication between an agent implementation and the
printer is of no concern to us, I've shown the agent as part of the
printer in all of the configurations.  

                       all         end-user
                    +-------+     +--------+
                    |monitor|     | client |
                    +---+---+     +--+--+--+
                        |            |  |
                        | +----------+  |
                        | |             |
                 +==+===+=+=+==+        |
                 |  | agent |  |        |
                 |  +-------+  |        |
                 |   PRINTER   +<-------+
                 |             | Print Job Delivery Channel
                 |             |
                 +=============+










XCMI Working Group                 File 40jobtc                 [Page 9]

XCMI Job Monitoring TC v5.10                           18 September 2002



4.2.  Configuration 2 - client-server-printer

In the client-server-printer configuration, the client(s) submit jobs to
an intermediate server by some network connection, not directly to the
printer.  

The job submitting client and/or monitor communicates directly with, in 
order of decreasing likelihood:  
    1.  an agent that is part of the server (or a front for the server),
        or 
    2.  an agent that is part of the printer (or a front for the
        printer), or 
    3.  both agents, one in the server and one in the printer 
The server may communicate with:  
    1.  the agent in the printer in order to monitor the jobs in the
        printer for the server's own purposes and/or to be a proxy agent
        to the client for the agent in the printer.  

                       all          end-user
                  +-------+     +----------+
                  |monitor|     |  client  |
                  +---+---+     +-+-+----+-+
                      |    \      | |    |
                      | +---\-----+ |    |
                      | |    \      |    v
                      | |     +=====+=+==+==+
                      | |     | agent |     |
                      | |     +-------+     |
                      | |     |    server   |
                      | |     +----+-----+--+
                      | |          |     |
                      | | +--------+     |
                      | | |              |
                 +==+=+=+=+====+         |
                 |  | agent |  |         |
                 |  +-------+  |         |
                 |   PRINTER   +<--------+
                 |             | Print Job Delivery Channel
                 |             |
                 +=============+













XCMI Working Group                File 40jobtc                 [Page 10]

XCMI Job Monitoring TC v5.10                           18 September 2002



4.3.  Configuration 3 - client-spooler-supervisor-printer

In the client-spooler-supervisor-printer configuration, the client(s)
submit jobs to an intermediate spooler, which in turn communicates with 
one or more supervisors which each control one or more printers.  

The job submitting client and/or monitor communicates directly with, in 
order of decreasing likelihood:  
    1.  an agent that is part of the spooler (or a front for the
        spooler), or 
    2.  an agent that is part of the supervisor (or a front for the
        supervisor), or 
    3.  an agent that is part of the printer (or a front for the
        printer) 
    4.  any combination of agents, one in the spooler, one in the
        supervisor, and one in the printer 





































XCMI Working Group                File 40jobtc                 [Page 11]

XCMI Job Monitoring TC v5.10                           18 September 2002

The spooler may communicate with, in order of decreasing likelihood:  
    1.  the agent in the supervisor in order to monitor the jobs in the 
        supervisor for the spooler's own purposes and/or to be a proxy
        agent to the client for the agent in the supervisor and/or
        printer.  
    2.  the agent in the printer in order to monitor the jobs in the
        printer for the spooler's own purposes and/or to be a proxy
        agent to the client for the agent in the printer.  

                     all          end-user
                  +-------+     +----------+
                  |monitor|     |  client  |
                  +---+-+-+     +-+-+----+-+
                      |  \ \      | |    |
                      | +---\-----+ |    |
                      | | \  \      |    v
                      | | |   +=====+=+==+==+
                      | | |   | agent |     |
                      | | |   +-------+     |
                      | | \   |   spooler   |
                      | |  \  +--+-+-----+--+
                      | |   \    | |     |
                      | | +------+ |     |
                      | | |   \    |     |
                      | | |    \   |     |
                      | | |   +=+==+==+==+==+
                      | | |   | agent |     |
                      | | |   +-------+     |
                      | | |   |  supervisor |
                      | | |   +----+-----+--+
                      | | |        |     |
                      | | | +------+     |
                      | | | |            |
                 +==+=+=+=+=+==+         |
                 |  | agent |  |         |
                 |  +-------+  |         |
                 |   PRINTER   +<--------+
                 |             | Print Job Delivery Channel
                 |             |
                 +=============+















XCMI Working Group                File 40jobtc                 [Page 12]

XCMI Job Monitoring TC v5.10                           18 September 2002



5.  CONVENTIONS

This section describes the conventions used in the Job Monitoring MIB.  


5.1.  Object Naming

The prefix for all objects in this MIB is "xcm", following the
conventions for each of the MIBs in the Xerox Common MIB standard.  

The names of each MIB object, as well as the specifications for each MIB
object, are copied directly from the corresponding job or document
attribute specification in the ISO DPA standard.  The DPA attribute
names are changed to conform to MIB conventions, by:  

    1.  Preceding each attribute with the prefix "xcm".  
        
    2.  Beginning each job attribute with the word "Job", if the DPA job
        attribute did not already begin with the "job-".  The "Job"
        first word also corresponds to the name of the table.  
        
    3.  Beginning each document attribute with the prefix "Doc", if the
        DPA document attribute did not already begin with "doc-".  DPA
        document attributes beginning with "document-" have been changed
        to begin with "Doc" for consistency.  The "Doc" first word also
        corresponds to the name of the table.  
        
    4.  Remove each hyphen (-) between words and capitalize the first
        letter of each word.  
        
        NOTE:  this transformation is also done for enum symbols.
        However, the descriptions of the objects that are taken directly
        from ISO DPA still use the hyphenated attribute and value OID
        names from ISO DPA.  The reader will have to translate from the 
        hyphenated names to the mixed case names.  
        
        For example, the ISO DPA document state:  transfer-pending is
        transformed into transferPending as an enum symbol.  
        
        The descriptions of bit-encoded values do not have any actual
        ASN.1 specified, so their names have remained as hyphenated
        names.  Implementers will have to define their own symbols for
        such bit encoded values.  For example, the second bit of
        XcmJMJobStateReasons textual convention is job-hold-set, so the
        implementer will have to define his own symbol, perhaps
        jobHoldSet.  
        
    5.  Rename some objects and enums to remove printer-centric meanings
        where they can be used for other types of job services.  

The order of the MIB objects follows the order of the corresponding DPA 
attributes, except that OPTIONAL MIB objects have been moved to separate

XCMI Working Group                File 40jobtc                 [Page 13]

XCMI Job Monitoring TC v5.10                           18 September 2002

groups, since each group must be all MANDATORY or all OPTIONAL (actually
conditional mandatory).  

Following SMI guidelines, each table is contained in a separate group.  
Since all objects are in tables in this MIB, so that multiple devices
can be supported (same as in the Printer MIB - see RFC 1759), the names 
of the groups and the names of the tables are the same.  

Attributes that are print-specific are put into a separate conditionally
mandatory group, so that a future multi-function MIB could represent a
scanner-only device, without requiring the print-specific group.  

The first line of each DESCRIPTION is the name of the corresponding ISO 
DPA attribute.  

    NOTE - For a few attributes it is necessary to include some specific
    MIB specification, along with the ISO DPA specification.  In such
    cases, the MIB-specific text precedes the ISO DPA attribute name and
    ISO DPA specification text which, in this case, starts with "ISO
    DPA:".  In certain cases, the ISO DPA specification is augmented
    with words inside square brackets ([]) so that it is clear what is
    taken from ISO DPA and what has been added by this MIB
    specification.  

The descriptions of new attributes (not from ISO DPA) are from a Xerox
Common DPA Extensions standard (work in progress) and are labeled
"(extension)".  Many of these DPA extensions will be proposed to the ISO
DPA committee, so they are labeled "(extension)" for now, rather than
"(Xerox extension)".  

At the end of each standard value description, the ISO DPA Object
Identifier (OID) name is indicated in parentheses, e.g.,
"(id-val-job-state-pending)".  


5.2.  Terminology

In this MIB specification, the terms "client" and "server" shall mean
the entity that submitted the job and the entity that accepted the job, 
respectively (via some other protocol than SNMP and not using this MIB).
The term "server" shall mean a printer or a software spooling system.
These terms are the same as those used in ISO DPA and the specifications
that have been copied from ISO DPA into this MIB specification.  

The terms "management station" and "SNMP agent" (or more simply "agent")
refer to the entity that submits SNMP requests and the entity that
accepts SNMP requests according to this MIB specification, respectively.
Thus it should be clear in this MIB specification when the specification
is referring to (1) the entities that submitted/accepted the print job
using some other protocol versus (2) those entities that are querying
the jobs and responding to job queries using SNMP and this MIB.  




XCMI Working Group                File 40jobtc                 [Page 14]

XCMI Job Monitoring TC v5.10                           18 September 2002



6.  DESCRIPTION OF THE JOB MONITORING MIB

This section describes salient aspects of the Job Monitoring MIB 


6.1.  Events

Traps are generated when any of the following MIB objects change values,
so that a management station can update the screen immediately, if it
wishes:  

    Job:
             job-priority
             current-job-state
             job-state-reasons*
             device-assigned
             device-state-of-devices-assigned*
             job-message-from-operator
             job-message-from-administrator

    Document:
             document-state

* traps are generated only when these attributes change while the job is
in the processing state.  


6.2.  Text Attributes

There are three different kinds of text strings used in MIBs:  

    1.  Strings that are represented as Network Virtual Terminal (NVT)
        ASCII and are never localized.  Such strings are specified in
        MIBs using the SMI textual convention:  DisplayString.  
        
    2.  Strings that are localized by the agent according to one or more
        locales specified by the management station.  A locale
        specification consists of a language, a country, and a coded
        character set.  Such strings are specified in MIBs using the SMI
        textual convention:  InternationalDisplayString.  
        
    3.  Strings that are represented in one or more coded character sets
        by the agent and that management stations can select which coded
        character set representation for the agent to return in a get by
        specifying the desired coded character set as an index.  Such
        strings are specified in MIBs using the (new) textual
        convention:  CodeIndexedStringIndex that point to objects of
        type CodeIndexedString.  

See the General textual-conventions for a description of the General
Current Localization group, the General Localization group, the General 
Code Indexed String group and the General Coded Char Set group in the

XCMI Working Group                File 40jobtc                 [Page 15]

XCMI Job Monitoring TC v5.10                           18 September 2002

General textual-conventions specification and module.  See the General
MIB for the objects in these groups that are intended to be used with
many MIBs.  


6.3.  The Job Information table & Document Information table

The job information table and the document information table are like
the Printer MIB (RFC 1759) alerts table, in that the printer (SNMP
agent):  

    1.  adds jobs to the job tables as the jobs are submitted to the
        printer (jobs are submitted to the printer via some protocol
        other than SNMP).  Each job is indexed using the job identifier 
        generated by the server when the job was submitted.  
        
    2.  removes jobs from the job tables when they have exceeded the
        time that retained and completed jobs remain in the table or are
        deleted (by SNMP or other protocol that is outside the scope of
        this MIB).  The agent MAY move such jobs into an so-called
        "Completed Job History" device, for an additional period of
        time.  See Section 7.5.  The OPTIONAL history device (see HRX
        MIB) allows jobs to be kept for a long time after the jobs
        complete without impacting the performance of applications that
        are accessing the more active or recently completed jobs.  
        
    3.  adds documents to the document table as the document part of
        each job is submitted to the printer (jobs contain one or more
        documents which are also submitted to the printer via some
        protocol other than SNMP).  Each document is indexed using both 
        the job identifier generated by the server when the job was
        submitted and the document sequence number which starts at 1 for
        the first document in a job.  
        
    4.  removes documents from the document table when the containing
        job is removed from the table or the document is deleted (by
        some protocol other than SNMP using this Job Monitoring MIB).  

The SNMP management station can access job information using the job
identifier generated by the printer (or print service) when the job was 
submitted (via some protocol other than SNMP).  

Jobs in the ISO DPA 'completed' state have very few job attributes,
while jobs in the 'retained' state have all their job and document
attributes.  Implementation of the 'retained' and 'completed' states is 
optional in ISO DPA.  ISO DPA requires that a completed job (if
implemented) have at least the following attributes:  job-identifier,
job-owner, current-job-state (with completed value), printers-assigned, 
and job-state-reasons.  

Similarly in this MIB, a job in the 'completed' state need no longer
retain the actual data for most of the objects (columns) that the job
contained while the job was in other states, including the 'retained'
state.  The purpose of the retained state is to permit a job to be

XCMI Working Group                File 40jobtc                 [Page 16]

XCMI Job Monitoring TC v5.10                           18 September 2002

reprinted again, while the purpose of the completed state is to keep a
record of completed jobs for some implementation-defined period of time.

The Xerox Job Model requires implementation of the completed state,
though the retained state is optional for level 1 and level 2
conformance.  In order for a management application to be able to copy
out the accounting objects from the Job Monitoring MIB, the accounting
objects shall be kept while the job is in the retained state, if
implemented, and the completed state, which shall be implemented.  

Conforming agents shall return values for the following objects for jobs
in the completed state (if the implementation-defined period is greater 
than 0):  

    xcmJobIdentifier            -- changed to xcmJobIdentifierOnSystem
    xcmJobOwner
    xcmJobName
    xcmJobCurrentState
    xcmPrintersAssignedTable    -- changed to xcmDevicesAssignedTable
                                -- (NOTE - this table is now deprecated)
    xcmJobStateReasons          -- added xcmJobXStateReasons for
                                -- (this sentence seems to be truncated,
                                -- but no old version has more text)
    xcmJobXStateReasons         -- Xerox extensions
    xcmJobX2StateReasons        -- Xerox extensions
    xcmJobAccountingUserName
    xcmJobAccountingInformation
    xcmJobStartedProcessingTime
    xcmJobImpressionsCompleted
    xcmJobMediaSheetsCompleted
    xcmJobCompletionTime
    xcmJobWorkUnitType          -- Xerox extension
    xcmJobUnitsOfWorkCompleted  -- Xerox extension

Agents may return empty values for the other objects for jobs in the
'completed' state.  


6.4.  Logical and physical printers

The ISO DPA standard permits a software printer object containing
printer attributes to represent either a logical printer, a physical
printer or both.  A logical printer is the abstraction to which users
submit jobs.  The physical printer is the abstraction that operators
deal with in managing the output devices.  

Using ISO DPA, the system administrator can create a logical printer
that is associated with more than one physical printer in order to
achieve load balancing across several output devices.  Also the system
administrator can create a number of logical printers (with different
defaults) that are associated with the same physical printer(s).  

In ISO DPA, a client can request job attributes by specifying either a
logical printer or a physical printer (see ISO DPA ListObjectAttributes 

XCMI Working Group                File 40jobtc                 [Page 17]

XCMI Job Monitoring TC v5.10                           18 September 2002

operation under the get-ordered-job sub-function).  When requesting jobs
associated with a logical printer, the DPA server shall return all jobs 
that are competing for the associated physical printers, not just the
jobs that were submitted to the specified logical printer.  

Conformance to this Job Monitoring MIB does not require the support of
the concept of logical devices, unless the agent is supporting a service
that has the concept of logical devices.  However, if logical printers
are supported, this Job Monitoring MIB requires that the SNMP agent also
return all jobs that are candidates for the physical printer(s)
associated with the specified logical printer.  So the high order table 
index for the job monitoring tables is the hrDeviceIndex from the Host
Resources MIB (RFC 1514).  Thus the device in the Host Resources MIB can
represent a logical printer or a physical printer.  

The Host Resources MIB (RFC 1514) already defines an OID for a printer
device type.  The means for indicating that a device in the Host
Resources MIB is a logical, a physical, or both a logical-and-physical
device is outside the scope of this Job Monitoring MIB.  Logical
printers might be represented by a new device type OID or by extension
of the Host Resources MIB with a new object that augments the device
type, so that any device, not just printers, could be indicated as
logical or physical.  The Xerox Common MIB has chosen the latter
approach (see the Host Resources Extension MIB).  


6.5.  Overview of the Job Monitoring MIB groups and tables

Following SMI recommendations, no group contains more than one table.
Since this MIB contains no scalar objects, since all objects are per-
printer and, therefore, indexed by hrDeviceIndex from the Host Resources
MIB, each group consists entirely of a single table.  Therefore, there
is a one to one correspondence between group names and table names.
Optional tables augment mandatory tables.  

Legend:
    Group Name  name of the group
    T           type of information in the group:
            G   general not device-type specific, so can be used by
                print jobs or by scan jobs (when a scan job MIB is
                written to augment this MIB)
            P   printer-centric
    U           usage:
            N   spooling not required, but may be used
                by a spooling device or component.
            S   spooling
    C           Conformance:
            C   conditionally mandatory (condition indicated in parens)
            O   optional
            D   deprecated
    N           number of objects in the group
    Table       table name
    Description description of the group


XCMI Working Group                File 40jobtc                 [Page 18]

XCMI Job Monitoring TC v5.10                           18 September 2002

The jobs MIB is divided into the following groups in the following
order.  The groups are categorized:  

    General     job service independent and device independent
                information for non-spooling and spooling systems.
    Printing    printing-specific information
    Spooling    job spooling information
    Accounting  accounting information
    Alerts      alert information used by all categories

  Group       T U C  N Table           Description
  -----       - - -  - -----           -----------

           -----------  General  ------------------------

  Base        G N C  6 Base            General Job Monitoring
                                       Base group.
                                      (MANDATORY if traps or SJMM)

  Job         G M C 12 JobGenBasic     General basic objects
  General                              for each job
  Basic                                spooling not required
                                      (MANDATORY if traps or SJMM)

  Devices     G N D  3 DevicesAssigned The table for the job that
  Assigned                             contains the hrDeviceIndex and
                                       the status of each of the
                                       physical devices to which the job
                                       has been assigned.

  Client      G N O  2 ClientIdMap     Maps client job ids to the system
  Id Map                               job ids:
                                       xcmJobIdentifierOnSystem
                                       that are used to index
                                       all other groups in the MIB.

  Job         G N C 17 JobGenExt       General additional objects
  General                              (spooling not required).
  Extended                             Augments the Job table with
                                       additional job objects
                                       for each job (device-type
                                       independent).  

  Document    G N C 10 DocGeneral      The mandatory document objects
  General              Basic           for each document in each job.
  Basic                                

           ------------  Printing  -----------------------

  Document    P N C  8 DocPrintingExt  The extended document
  Printing                             print-specific document table
  Extended                             that augments the Document table
                                       with additional print-centric
                                       document attributes.  

XCMI Working Group                File 40jobtc                 [Page 19]

XCMI Job Monitoring TC v5.10                           18 September 2002


           -----------  Spooling  ------------------------

  Job         P S C  5 JobGen          The conditionally mandatory job
  General              SpoolingBasic   table that augments the Job table
  Spooling                             with additional general
  Basic                                job attributes for each job,
                                        i.e., is mandatory for agents
                                       that support spooling.  

  Job         P S C  8 JobGen          The extended job table that
  General              SpoolingExt     augments the Job table
  Spooling                             with additional general
  Extended                             job attributes for each job.

           -----------  Accounting  ------------------------

  Job         G N C  6 JobGen          The basic job
  General              Accounting      accounting table.  
  Accounting           Basic           
  Basic

  Media       P N C  5 MediaConsumed   The media types and amounts
  Consumed                             consumed by each job.

  Color       P N C  4 ColorImpressions The colors and amounts consumed
  Impressions          Consumed         by each job.  
  Consumed                              

  Impressions P N C  6 JobImps         Job impressions consumed
  Consumed             ByMediumSize    by Medium Size.  
  By Medium                            
  Size

          ----------------  Alerts  -----------------------------

  Job Alert   G N C  2 none            The job alert objects.
                                      (MANDATORY if traps)

  Document    G N M  2 none            The document alert objects.
  Alert                                



6.6.  Minimal Implementation: only 17 accessible objects

Conformance to this specification no longer requires implementing the
PWG Job Monitoring MIB; either this MIB and/or the PWG MIB may be used.
With the PWG MIB, conformance to this specification does not require
implementing any of the groups in this specification.  However, if traps
are needed, then the CONDITIONALLY MANDATORY xcmJMBaseGroup,
xcmJMJobGenBasicGroup, and xcmJMJobAlertGroup SHALL be implemented.  If
the Simple Job Management MIB (SJMM) is implemented, then the
CONDITIONALLY MANDATORY xcmJMBaseGroup and xcmJMJobGenBasicGroup SHALL

XCMI Working Group                File 40jobtc                 [Page 20]

XCMI Job Monitoring TC v5.10                           18 September 2002

be implemented.  If the device only contains one job at a time, the
device need implement only one row of the xcmJobGeneralBasicTable.  Thus
the total number of accessible objects for a minimal implementation is
only:  6+11=17 accessible objects.  The total number of mandatory groups
is 2, each table need have only one row for this minimal system.  


















































XCMI Working Group                File 40jobtc                 [Page 21]

XCMI Job Monitoring TC v5.10                           18 September 2002



7.  CONFORMANCE REQUIREMENTS AND IMPLEMENTERS GUIDE

This section specifies the conformance requirements for the XCMI Job
Monitoring MIB and the industry standard PWG Job Monitoring MIB for:  

    1.  conforming agents in devices and servers 
    2.  conforming clients 


7.1.  Conformance req'ts for agents in devices & servers

Conformance to this XCMI Job Monitoring MIB specification requires that 
servers and devices implement SNMP agents that conform as follows:  

    1.  When the PWG Job Mon MIB is implemented, the additional
        requirements specified below shall be adhered to.  
        
    2.  When the PWG Job Mon MIB is implemented, the implementations
        SHALL also follow the recommendations for representing their
        implemented job submission protocols in the PWG Job Monitoring
        MIB as specified in the PWG "Job Submission Protocol Mapping to
        the Job Monitoring MIB" specification [MAP].  
        
    3.  In addition, such devices and servers SHALL implement certain
        groups in the XCMI Job Mon MIB, if and only if certain
        conditions exist.  See section 7.2 for details on XCMI Job Mon
        conditional conformance.  


























XCMI Working Group                File 40jobtc                 [Page 22]

XCMI Job Monitoring TC v5.10                           18 September 2002

The following table lists all of the PWG job monitoring MIB objects and 
attributes and indicates whether the XCMI Coherence standard requires
their implementation or not by agents.  

NOTE:  these conformance requirements are stronger than the conformance 
requirements in the PWG Job Monitoring MIB, in order to improve Xerox
Coherence.  The PWG Job Monitoring MIB only requires an agent to
implement an attribute if the data exists and the agent has access to
it.  The XCMI Coherence standard requires that an XCMI conformant device
or server support the PWG attributes as indicated (and ensure that the
agent has access to the data):  

               TABLE - Agent Conformance Requirements
Legend:
     SHALL     it is required for the agent to support
     COND      it is CONDitionally required for the agent to support,
               i.e., it is required if the device or server implements
               the functionality that the attribute represents
     COND-cp   required if the device is a Color Printer
     COND-mc   required if the device/server supports Multiple Copies
     COND-md   required if Multiple Documents per job are supported
               (start, banner, and end sheets do not count as documents)
     COND-pm   required if the device/server implements the Printer MIB
     COND-us   required if the device/server supports Upstream Servers
     MAY       it is optional for the agent to support
     DEPRECATED     it is required that the agent NOT support the
               attribute, either because it is a bad idea, or is
               duplicated by other attribute(s).

     Data types:
     bits      bits in an integer type
     bool      Boolean
     enum      enum data type
     int       integer data type representing a number
     idx       index into the Printer MIB
     oct       octet string, e.g., a structure or opaque data
     str       text string

     (NOTES are indicated in parentheses)

PWG jmGeneralGroup:                    type       agents
------------------                     ----       ------
jmGeneralNumberOfActiveJobs            int        SHALL
jmGeneralOldestActiveJobIndex          idx        SHALL
jmGeneralNewestActiveJobIndex          idx        SHALL
jmGeneralJobPersistence                int        SHALL
jmGeneralAttributePersistence          int        SHALL
jmGeneralJobSetName                    str        SHALL

PWG jmJobIDGroup:                                 agents
----------------                                  ------
jmJobIDJobSetIndex                     idx        SHALL
jmJobIDJobIndex                        idx        SHALL


XCMI Working Group                File 40jobtc                 [Page 23]

XCMI Job Monitoring TC v5.10                           18 September 2002


PWG jmJobGroup:                        type       agents
--------------                         ----       ------
jmJobState                             enum       SHALL
jmJobStateReasons1                     bits       SHALL
jmNumberOfInterveningJobs              int        SHALL
jmJobKOctetsPerCopyRequested           int        SHALL
jmJobKOctetsProcessed                  int        SHALL
jmJobImpressionsPerCopyRequested       int        SHALL
jmJobImpressionsCompleted              int        SHALL
jmJobOwner                             str        SHALL

The following job state reason bits SHALL be implemented:
    deviceStopped (0x400)*             equivalent to DPA
                               "printer-state-of-printers-assigned"
    jobCanceledByUser (0x2000)
    abortedBySystem (0x10000)
    processingToStopPoint (0x20000)  == DPA/XCMI 'terminating' job state
    serviceOffLine (0x40000)
    jobCompletedSuccessfully (0x80000)
    jobCompletedWithWarnings (0x100000)
    jobCompletedWithErrors (0x200000)
    jobRetained (0x1000000)*           == DPA/XCMI 'retained' job state

"*" indicates that there is no equivalent XCMI job state reason bit.  

The remaining job state reason bits in jmJobStateReasons1 and
jobStateReasonsN (N=2..4) are CONDITIONALLY MANDATORY, i.e., they SHALL 
be implemented if the server or device supports the reason represented
by the bit.  

PWG jmAttributeGroup                   type       agents:
--------------------                   ----       ------
jmAttributeValueAsInteger              int/enum   SHALL
jmAttributeValueAsOctets               str/oct    SHALL

PWG Attributes                         type       agents:
--------------                         ----       ------
other(1)                               int        DEPRECATED
                                       str        DEPRECATED
Job State attributes (3-19):
jobStateReasons2(3)                    bits       COND
jobStateReasons3(4)                    bits       COND
jobStateReasons4(5)                    bits       COND
processingMessage(6)                   str        COND
processingMessageNaturalLangTag(7)     str        COND
jobCodedCharSet(8)                     int        SHALL
jobNaturalLanguageTag(9)               str        COND

Job Identification attributes (20-49):
jobURI(20)                             str        COND
jobAccountName(21)                     str        COND
serverAssignedJobName(22)              str        COND
jobName(23)                            str        SHALL

XCMI Working Group                File 40jobtc                 [Page 24]

XCMI Job Monitoring TC v5.10                           18 September 2002

jobServiceTypes(24)                    int        COND
    (SHALL if device more than prints, MAY if device only print)
jobSourceChannelIndex(25)              idx        COND-pm
jobSourcePlatformType(26)              enum       MAY
submittingServerName(27)               str        COND-us
submittingApplicationName(28)          str        COND
jobOriginatingHost(29)                 str        COND
deviceNameRequested(30)                str        COND
queueNameRequested(31)                 str        COND
physicalDevice(32)                     idx        COND
    (SHALL if multiple printer devices or multiple service types)
                                       str        MAY
numberOfDocuments(33)                  int        COND-md
fileName(34)                           str        COND-md
documentName(35)                       str        COND-md
jobComment(36)                         str        COND
documentFormatIndex(37)                idx        COND-pm
    (Only need one row per document, even if wrapped in another PDL)
documentFormat(38)                     enum       COND
                                       str        COND

PWG Attributes                         type       agents:
--------------                         ----       ------
Job Parameter attributes (50-69):
jobPriority(50)                        int        COND
jobProcessAfterDateAndTime(51)         str        COND
jobHold(52)                            bool       DEPRECATED
    (is redundant with jmJobStateReasons1 jobHoldSet reason)
jobHoldUntil(53)                       str        COND
outputBin(54)                          idx        COND-pm
                                       str        COND
sides(55)                              int        SHALL
finishing(56)                          enum       COND

Image Quality attributes (requested and used) (70-89):
printQualityRequested(70)              enum       COND
printQualityUsed(71)                   enum       SHALL
printerResolutionRequested(72)         oct        COND
printerResolutionUsed(73)              oct        SHALL
tonerEcomonyRequested(74)              enum       COND
tonerEcomonyUsed(75)                   enum       COND
tonerDensityRequested(76)              enum       COND
tonerDensityUsed(77)                   enum       COND

Job Progress attributes (requested and consumed) (90-109):
jobCopiesRequested(90)                 int        COND
jobCopiesCompleted(91)                 int        COND
documentCopiesRequested(92)            int        COND-md
documentCopiesCompleted(93)            int        COND-md
jobKOctetsTransferred(94)              int        MAY
sheetCompletedCopyNumber(95)           int        COND-mc
sheetCompletedDocumentNumber(96)       int        COND-md
jobCollationType(97)                   enum       COND-md


XCMI Working Group                File 40jobtc                 [Page 25]

XCMI Job Monitoring TC v5.10                           18 September 2002


Impression attributes (requested and consumed) (110-129):
impressionsSpooled(110)                int        MAY
impressionsSentToDevice(111)           int        MAY
impressionsInterpreted(112)            int        MAY
impressionsCompletedCurrentCopy(113)   int        COND-mc
fullColorImpressionsCompleted(114)     int        COND-cp
highlightColorImpressionsCompleted(115)int        COND-cp

Page attributes (requested and consumed) (130-149):
pagesRequested(130)                    int        MAY
pagesCompleted(131)                    int        MAY
pagesCompletedCurrentCopy(132)         int        MAY

PWG Attributes                         type       agents:
--------------                         ----       ------
Sheet attributes (requested and consumed) (150-169):
sheetsRequested(150)                   int        MAY
sheetsCompleted(151)                   int        SHALL
sheetsCompletedCurrentCopy(152)        int        COND-mc

Resource attributes (requested and consumed) (170-189):
mediumRequested(170)                   enum       MAY
                                       str        MAY
mediumConsumed(171)                    enum       COND
                                       AND (both values req.)
                                       str        COND
colorantRequested(172)                 int        MAY
                                       str        MAY
colorantConsumed(173)                  int        MAY
                                       str        MAY
    (fullColorImpressionsCompleted gives sufficient color info)

Time attributes (set by server or device) (190-209):
jobSubmissionToServerTime(190)         int        COND-us
                                       str        COND-us
jobSubmissionTime(191)                 int        SHALL
                                       str        COND
jobStartedBeingHeldTime(192)           int        COND-hj
                                       str        COND-hj
jobStartedProcessingTime(193)          int        MAY
                                       str        MAY
jobCompletionTime(194)                 int        SHALL
                                       str        COND
jobProcessingCPUTime(195)              int        MAY


7.1.1.  Use of Registered PWG attributes

Any future attributes registered by the PWG for use with the PWG Job
Monitoring MIB, are automatically available to Xerox conforming
implementations without requiring updating this specification.  For a
list of the approved registered PWG Job Monitoring MIB attributes, see:


XCMI Working Group                File 40jobtc                 [Page 26]

XCMI Job Monitoring TC v5.10                           18 September 2002


    ftp://ftp.pwg.org/pub/pwg/jmp/approved-registrations/ 

An agent MAY implement any registered attributes, but such registered
attributes are NOT CONDITIONALLY MANDATORY just because they are
registered (see Section 7.1).  Making any such attribute registrations
MANDATORY (SHALL) or CONDITIONALLY MANDATORY (COND) will require
updating this XCMI document.  


7.2.  XCMI Job Monitoring MIB conformance requirements

Devices and servers SHALL NOT support any XCMI Job Monitoring MIB
groups, unless traps and/or the XCMI Simple Job Management MIB (SJMM)
are needed.  If either of these conditions are true, the agent SHALL
also implement the CONDITIONALLY MANDATORY xcmJMBaseGroup and
xcmJMJobGenBasicGroup.  If traps are needed, then the agent SHALL also
implement the CONDITIONALLY MANDATORY xcmJMJobAlertGroup and MAY
implement the OPTIONAL xcmJMClientIdMapGroup.  

The following table lists all the groups in the XCMI MIB and indicates
their conformance status:  

    COND       CONDITIONALLY MANDATORY, if the indicated condition is
               true and SHALL NOT be implemented if the condition is
               NOT true.
    MAY        OPTIONAL if the indicated condition is true and SHALL NOT
               be implemented if the condition is NOT true.
    deprecated supported by agents in some current products, but which
               SHALL NOT be supported by agents conforming to this
               version of this standard.
    deleted    SHALL NOT be implemented by any agents and SHALL NOT be
               supported by any clients.  (They were present in V2.4)

    XCMI Groups (no. of objects)         agent conformance requirements
    ----------------------------         ------------------------------
    xcmJMBaseGroup (7)                   COND if traps and/or SJMM
    xcmJMJobGenBasicGroup (12)           COND if traps and/or SJMM
    xcmJMDevicesAssignedGroup (3)        deprecated
    xcmJMClientIdMapGroup (1)            MAY if traps and/or SJMM
    xcmJMJobStateMsgGroup                deleted
    xcmJMJobGenExtGroup (18)             COND in v4
    xcmJMJobTreeBasicGroup               deleted
    xcmJMDocGenBasicGroup (10)           was deleted, COND in v4
    xcmJMDocPrintExtGroup (8)            was deleted, COND in v4
    xcmJMJobGenSpoolingBasicGroup (5)    COND in v4 for
                                         agents that support spooling
    xcmJMJobGenSpoolingExtGroup (9)      was deleted, COND in v4
    xcmJMJobGenAccountingBasicGroup (9)  COND in v4
    xcmJMMediaConsumedGroup (5)          COND in v4
    xcmJMColorImpsConsumedGroup (4)      was deleted, COND in v4
    xcmJMJobImpsByMediumSizeGroup (6)    COND in v4
    xcmJMJobAlertGroup (1)               COND if traps and/or SJMM
    xcmJMDocAlertGroup (1)               was deleted, COND in v4

XCMI Working Group                File 40jobtc                 [Page 27]

XCMI Job Monitoring TC v5.10                           18 September 2002



7.3.  Client conformance requirements

Clients SHALL implement the PWG Job Monitoring MIB.  Furthermore, for
the foreseeable future, clients SHALL also implement the XCMI Job
Monitoring MIB to the same degree that they implement the PWG Job
Monitoring MIB, as long as the XCMI object is not indicated as deleted
in this version of the specification.  In other words, if a client
supports a PWG object or attribute, it SHALL support the same object in 
the XCMI Job Mon MIB, if the object is not indicated as deleted in this 
specification.  

Since the objects and attributes that a client supports depends on the
nature of the client (e.g., document monitoring, queue displaying,
accounting, capital assessment, printer supervisor, etc.), this
specification cannot require any particular objects or attributes to be 
implemented by a client.  

A client SHALL NOT depend on an attribute being present that this
document indicates that an agent SHALL implement.  Thus a client SHALL
work correctly (perhaps with slower performance since some retries may
be necessary) with a non-XCMI conforming device, such as a device from
another vendor.  However, a client SHOULD optimize its performance
assuming that such attributes are present.  Thus the application will
show best performance with XCMI conformant devices.  

To help with migration from the XCMI Job Monitoring MIB to the PWG Job
Monitoring MIB, the following table maps all XCMI objects (including the
deleted ones) to the PWG Job Monitoring MIB objects and attributes.  

Legend:
     ~         means similar to in data type and/or semantics
     -         means not available in the PWG Job Mon MIB
     bits      bits
     date      DateAndTime
     enum      enum
     idx       index
     locstr    CodeIndexedStringIndex (localized string)
     oct       octet string
     oid       Object Identifier (OID)
     rs        RowStatus
     str       string (unlocalized)

XCMI object                             PWG object/attribute
-----------                             --------------------
XcmJobMonBaseEntry (CONDITIONALLY MANDATORY - traps and/or SJMM):
xcmJobMonBaseIndex (idx)                -
xcmJobMonBaseRowStatus (rs)             -
xcmJobMonBaseVersionID (str)            -
xcmJobMonBaseVersionDate (date)         -
xcmJobMonBaseGroupSupport (bits)        -
xcmJobMonBaseCreateSupport (bits)       -
xcmJobMonBaseUpdateSupport (bits)       -

XCMI Working Group                File 40jobtc                 [Page 28]

XCMI Job Monitoring TC v5.10                           18 September 2002


XcmJobGenBasicEntry (CONDITIONALLY MANDATORY - traps and/or SJMM):
xcmJobIdentifierOnSystem (str)          ~ jmJobIndex
xcmJobClientId (str)                    jmJobSubmissionID
xcmJobServiceType (oid)                 jobServiceTypes(24)
xcmJobName (locstr)                     jobName(23)
xcmJobOwner (locstr)                    jmJobOwner
xcmJobSourceChannelType (enum)          jobSourceChannelIndex(25)
xcmJobSubmittedLocaleIndex (idx)        jobCodedCharSet(8),
                                        jobNaturalLanguageTag(9)

xcmJobCurrentState (enum)               jmJobState
xcmJobStateReasons (bits)               jmJobStateReasons1
xcmJobXStateReasons (bits)              jobStateReasonsN (N=2-4)
xcmJobX2StateReasons (bits)             jobStateReasonsN (N=2-4)

XcmDevicesAssignedEntry (DEPRECATED):
xcmDevicesAssignedHrDeviceIndex (idx)   physicalDevice(32) idx
xcmDeviceStateOfDevicesAssigned (enum)  -
xcmJobIdentifierDownstream (str)        -

XcmClientIdMapEntry (OPTIONAL):
xcmClientIdMapJobIdOnSystem (str)       jmJobSubmissionID
xcmClientIdMapHrDeviceIndex (idx)       jmJobIndex

XcmJobStateMsgEntry (DELETED):
xcmJobStateMsgIndex (idx)               -
xcmJobStateMsgLocalizationIndex (idx)   -
xcmJobStateMsgMessage (str)             -

XCMI object                             PWG object/attribute
-----------                             --------------------
XcmJobGenExtEntry  
xcmJobOriginator (locstr)               -
xcmJobSubmittingApplication (locstr)    submittingApplicationName(28)
xcmJobComment (locstr)                  jobComment(36)
xcmJobCopies (int)                      jobCopiesRequested(90)
xcmJobCopiesCompleted (int)             jobCopiesCompleted(91)
xcmJobOutputBinIndex (idx)              outputBin(54)
xcmJobServiceNameRequested (locstr)     deviceNameRequested(30)
xcmJobPreviousState (enum)              -
xcmJobEstimatedCompletionTime (date)    -
xcmJobSubmissionTime (date)             jobSubmissionTime(191)
xcmJobPagesCompleted (int)              pagesCompleted(131)
xcmJobOctetsCompletedHigh (int)         jmJobKOctetsCompleted
xcmJobOctetsCompletedLow (int)          jmJobKOctetsCompleted
xcmJobErrorCount (int)                  -
xcmJobWarningCount (int)                -
xcmJobProcessingTime (int)              jobProcessingCPUTime(195)
xcmJobNumberOfDocuments (int)           numberOfDocuments(33)
xcmJobAuthorizationUserName (locstr)    jmJobOwner

XcmDocGenBasicEntry 
xcmDocSequenceNumber (int)              ~ jmAttributeInstanceIndex

XCMI Working Group                File 40jobtc                 [Page 29]

XCMI Job Monitoring TC v5.10                           18 September 2002

xcmDocName (locstr)                     documentName(35)
xcmDocFileName (locstr)                 fileName(34)
xcmDocFileNameType (enum)               -
xcmDocType (enum)                       -
xcmDocFormat (enum)                     documentFormat(38) enum
xcmDocFormatVariants (locstr)           ~ documentFormatIndex(37)
xcmDocFormatVersion (locstr)            ~ documentFormatIndex(37)
xcmDocOctetCount (int)                  jmJobKOctetsPerCopyRequested
xcmDocState (enum)                      -

XcmDocPrintExtEntry 
xcmDocPrintDefaultMediumName (str)      ~ mediumRequested(170) str
xcmDocPrintDefaultInputIndex (idx)      -
xcmDocPrintFinishing (str)              ~ finishing(56) enum
xcmDocPrintOutputMethod (enum)          -
xcmDocPrintNumberUp (str)               -
xcmDocPrintSides (int)                  sides(55)
xcmDocPrintCopyCount (int)              documentCopiesRequested(92)
xcmDocPrintCopiesCompleted  (int)       documentCopiesCompleted(93)

XcmJobGenSpoolingBasicEntry 
xcmJobNumberOfJobResultSets (int)       -
xcmJobPriority (int)                    jobPriority(50)
xcmJobTotalOctetsHigh (int)             jmJobKOctetsPerCopyRequested
xcmJobTotalOctetsLow (int)              jmJobKOctetsPerCopyRequested
xcmJobInterveningJobs (int)             jmNumberOfInterveningJobs

XCMI object                             PWG object/attribute
-----------                             --------------------
XcmJobGenSpoolingExtEntry 
xcmJobProcessAfter (date)               jobProcessAfterDateAndTime(51)
xcmJobDeadlineTime (date)_              -
xcmJobDiscardTime (date)                -
xcmJobRetentionPeriod (int)             -
xcmJobMessageToOperator (locstr)-
xcmJobMessageFromOperator (locstr)      -
xcmJobMessageFromAdministrator (locstr) -
xcmJobPageCount (int)                   pagesRequested(130)

XcmJobGenAccountingBasicEntry 
xcmJobAccountingBasicRowStatus (rs)     -
xcmJobAccountingUserName (locstr)       jmJobOwner
xcmJobAccountingInformation (oct)       jobAccountName(21)
xcmJobStartedProcessingTime (date)  jobStartedProcessingDateAndTime(74)
xcmJobImpressionsCompleted (int)        jmJobImpressionsCompleted(55)
xcmJobMediaSheetsCompleted (int)        sheetsCompleted(61)
xcmJobCompletionTime (date)             jobCompletedTime(194)
xcmJobWorkUnitType (enum)               -
xcmJobUnitsOfWorkCompleted (int)        -

XcmMediaConsumedEntry 
xcmMediaConsumedIndex (idx)             -
xcmMediaConsumedRowStatus (rs)          -
xcmMediaConsumedType (enum)             mediumRequested(170) enum

XCMI Working Group                File 40jobtc                 [Page 30]

XCMI Job Monitoring TC v5.10                           18 September 2002

xcmMediaConsumedName (locstr)           mediumConsumed(171) str
xcmMediaConsumedSheetCount (int)        mediumConsumed(171) int

XcmColorImpsConsumedEntry 
xcmColorImpsConsumedIndex (idx)         -
xcmColorImpsConsumedRowStatus (rs)      -
xcmColorImpsConsumedTypeIndex (enum)    colorantConsumed(173)
xcmColorImpsConsumedCount (int)         -

XcmJobImpsByMediumSizeEntry 
xcmJobImpsByMediumSizeIndex (idx)       -
xcmJobImpsByMediumSizeRowStatus (rs)    -
xcmJobImpsByMediumSizeMediumSize (str)  ~ mediumConsumed(171) str
xcmJobImpsByMediumSizeCountType (enum)  ~ mediumRequested(170) enum
xcmJobImpsByMediumSizeCount (int)       ~ mediumConsumed(171) int

xcmJobAlert (CONDITIONALLY MANDATORY - if need traps):
xcmJobV1AlertNew                        -

xcmDocAlert 
xcmDocV1AlertNew                        -


7.4.  Hints to improve Client performance with SNMPv1

Integer attributes are more likely to change than octet string
attributes.  Octet string attributes tend to be fixed when the job is
submitted.  Therefore, a monitoring application need not re-fetch octet 
string attributes for a job, after fetching them once.  An exception is 
the jobProcessingMessage(6) attribute.  

Because SNMPv1 returns an error if any requested object in a PDU is not 
implemented, a client needs to be careful how it combines objects into a
PDU when accessing the attributes table.  Conformance to the XCMI Job
Mon MIB, requires that the agent support some attributes (whether the
agent has data for the attribute or not).  For all the other attributes,
an agent NEED NOT implement an attribute unless it supports that
attribute and has data for it.  So when requesting integer attributes
that change, the client SHOULD request one attribute from a sequence of 
jobs that were in the table at the last poll cycle, using GetNext for
each attribute in the PDU.  Then if a job has disappeared, the GetNext
will get the same attribute twice for the immediately following job.  

This strategy works because the order of arcs in the OID is:  
  jmAttributeValueAsInteger, job set, job id, attribute id, instance idx
  jmAttributeValueAsOctets, job set, job id, attribute id, instance idx 

An application that wants to display active and held jobs, but not
completed jobs, should first use the PWG jmGeneralOldestActiveJobIndex
to start with the oldest active job, since this will by-pass most, if
not all, of the 'completed' jobs.  Then the application can fetch all
the jobs adding only the 'held' jobs to the display.  



XCMI Working Group                File 40jobtc                 [Page 31]

XCMI Job Monitoring TC v5.10                           18 September 2002



7.5.  The OPTIONAL "Completed Job History" device

The "Completed Job History" device is a pseudo device that is OPTIONAL
for implementation for use with either the XCMI Job Mon MIB or the PWG
Job Mon MIB.  The History device solves the performance problem for
devices that could have a large number of completed jobs in the job
tables:  

    An agent MAY implement the "job history" device that contains
    completed jobs for a long period of time.  Such a device permits the
    agent to keep a lot of jobs in the 'completed' state without
    impacting the performance of application programs that start up and 
    have to copy the entire job table (because they want to display held
    jobs as well as active jobs).  In such an agent implementation, jobs
    SHALL remain in the PWG (and XCMI Job tables) for a short period of 
    time (see PWG jmGeneralJobPersistence and
    jmGeneralAttributePersistence objects) in the 'completed' state with
    the 'jobRetained' job state reason bit set (corresponding to the DPA
    and Xerox Job Model 'retained' job state), but long enough so that
    accounting applications can copy out the results, without being
    dependent on the OPTIONAL "job history" device.  Then the agent
    moves the jobs to the History device, such that the job never
    appears in both devices at the same time.  
    
    The HRX MIB would have a pointer from the real device to the "job
    history" device.  To keep applications from thinking that the new
    device was a printer, a new "job history device type" OID has been
    assigned.  See the HRX MIB.  

























XCMI Working Group                File 40jobtc                 [Page 32]

XCMI Job Monitoring TC v5.10                           18 September 2002



8.  JOB MONITORING MIB TEXTUAL CONVENTIONS

The Job Monitoring MIB textual conventions include type 2 and type 3
enums - see the Printer MIB (RFC 1759) for discussion of type 1, 2, and 
3 enums.  Therefore, only the XEROX-JOB-MONITORING-TC module need be
republished when a new enum value needs to be added; the XEROX-JOB-
MONITORING-MIB module itself does not.  

The following textual-conventions are imported from the SNMPv2 TC (RFC
1443):  

    DisplayString              Particular subset of US-ASCII,
                               called network virtual terminal (NVT)
                               ASCII.  Such strings need not be
                               localized.
    DateAndTime                Date and time, including time zones
    RowStatus                  To allow management stations to create
                               and destroy rows in tables.

The following textual-conventions are imported from the General MIB (see
06gentc.txt):  

    Ordinal16                  1..2**15-1  (don't use sign bit)
    Cardinal16                 0..2**15-1  (don't use sign bit)
    Ordinal32                  1..2**31-1  (don't use sign bit)
    Cardinal32                 0..2**31-1  (don't use sign bit)
    Cardinal64High             0..2**31-1  (high 31 bits of 62-bits)
    Cardinal64Low              0..2**31-1  (low 31 bits of 62-bits)'
    CodeIndexedStringIndex     index to GenCodedStringTable
                               for CodeIndexedStringIndex objects

The following textual-conventions are imported from the Printer
Extensions MIB (NOTE:  the PWG is making them textual conventions in the
draft Printer MIB, so we should change to import from there when the RFC
is published):  

    XcmPrtChannelType           Channel type enums defined in  the
                                Printer MIB (RFC 1759).
    XcmPrtInterpreterLangFamily Document format enums
                                defined in the Printer MIB
                                (RFC 1759)

The following textual-conventions are imported from the Xerox Host
Resources Extension textual conventions (see 10hosttc.txt):  

    XcmHrDevInfoXStatus        Devices states: has separate
                               device-specific ranges of enums for
                               each device type: printers, scanners,
                               faxes, document-distribution, etc.
                               So we can keep the ISO DPA names
                               for the printer states as they are.
                               Devices can be purely software.

XCMI Working Group                File 40jobtc                 [Page 33]

XCMI Job Monitoring TC v5.10                           18 September 2002

                               Devices differ from Job Services
                               in that devices can be managed using
                               the appropriate device MIB.  For example,
                               the printer MIB, the scanner MIB, or the
                               FAX MIB.  Job Services (like logical
                               devices) could be monitored by the
                               Network Service Monitoring (NSM) MIB.
                               See RFC 1565, Jan 1994 and recent
                               Internet Drafts.

                               Some job services will have entries in
                               the Host Resources Device table along
                               with their physical device counterpart,
                               e.g., logical printer(s) and their
                               corresponding physical printer.

The following textual-conventions for enum values are defined here in
the XEROX-JOB-MONITORING-TC:  

    XcmJMJobState              Job states from ISO DPA
    XcmJMJobStateReasons       Job state reasons bit encoded
                               but derived from ISO DPA
    XcmJMJobXStateReasons      Job state reason extensions
                               bit encoded for Xerox
    XcmJMJobX2StateReasons     Job state reason extensions number 2
                               bit encoded for Xerox
    XcmJMMediumType            Medium type (stationery, transparency,
                               etc.) from ISO DPA medium object.
    XcmJMImpsCountType         Type of how to count impressions

These types have enum values that are algorithmically derived from the
last arc of the corresponding ISO DPA OBJECT IDENTIFIER by adding an
offset of 0, 2, or 3, depending on the enum.  The offset is indicated
for each object in an ASN.1 comment.  The bit-coded values are
algorithmically derived from the corresponding ISO DPA OBJECT
IDENTIFIERS.  

The following textual-convention for OID values is defined here in the
XEROX-JOB-MONITORING-TC:  

    XcmJMJobServiceTypeOID   Job service type, e.g.,
                             xcmJobServiceScanToFileOID,
                             xcmJobServicePrintOID












XCMI Working Group                File 40jobtc                 [Page 34]

XCMI Job Monitoring TC v5.10                           18 September 2002



9.  MANAGED OBJECT DEFINITIONS



9.1.  Definition of JM Textual Conventions

XEROX-JOB-MONITORING-TC DEFINITIONS ::= BEGIN

--
--
-- Date:    9-Apr-2002
-- Version: 5.11.pub
-- File:    40jobtc.dfm, .mib, .pdf, .txt

IMPORTS
        MODULE-IDENTITY, OBJECT-IDENTITY, OBJECT-TYPE
               FROM SNMPv2-SMI                   -- RFC 1442/1902/2578
        TEXTUAL-CONVENTION
               FROM SNMPv2-TC                    -- RFC 1443/1903/2579
        xeroxCommonMIB
               FROM XEROX-COMMON-MIB;            -- 02common.mib

xcmJobMonTC MODULE-IDENTITY
        LAST-UPDATED "0209170000Z"  -- yymmddhhmmZ, year 20yy
        ORGANIZATION "Xerox Corporation - Common MIB Working Group"
        CONTACT-INFO
        "       XCMI Editors
                E-Mail:       coherence@crt.xerox.com

                --
                --
        "
        DESCRIPTION "
            File:     40jobtc.dfm, .mib, .pdf, .txt
            Version:  5.11.pub

            This textual-convention module defines textual-
            conventions for use with the Job Monitoring MIB,
            module:  XEROX-JOB-MONITORING-MIB.  Also the explanatory
            material with this module explains the Job Monitoring

XCMI Working Group                File 40jobtc                 [Page 35]

XCMI Job Monitoring TC v5.10                           18 September 2002

            MIB.  These textual-conventions and explanations are in
            a separate module from the Job Monitoring MIB, so that
            they may be republished when additional enums are added
            or more explanatory material is added without needing to
            republish the Job Monitoring MIB, thus increasing the
            stability of the Job Monitoring MIB.
            Copyright 1996-2002 Xerox Corporation. All Rights Reserved."
        ::= { xeroxCommonMIB 58 }

-- definitions of textual conventions

XcmJMJobServiceTypeOID ::= TEXTUAL-CONVENTION
    STATUS     current
    DESCRIPTION
        "Specifies the type of service to which the job has been
        submitted.  The service type is represented as a single OID,
        rather than as an OID for a source-type and an OID for a
        destination-type, so that more general and arbitrary service
        types can be created, such as services with more than one
        destination type, or ones with only a source or only a
        destination."
    SYNTAX     OBJECT IDENTIFIER

--
--                REGISTRY of Job Service Type OIDs
--                (used as values of the
--                Job Monitoring MIB xcmJobServiceType object)
--
--  Usage:  Developers should ALWAYS request registration of appropriate
--  XCMI standard job service type OIDs when they design or integrate
--  basic services into a job service to which job service requesters
--  can submit job requests.

xcmJobServiceTypesOID OBJECT-IDENTITY
    STATUS     current
    DESCRIPTION
        "The root of all job service type OIDs defined in the Job
        Monitoring MIB TC.  Also use these same OIDs for Xerox
        extensions to ISO DPA."
    ::= { xcmJobMonTC 2 }

xcmJobServiceScanToFileOID OBJECT-IDENTITY
    STATUS     current
    DESCRIPTION
        "Scan-to-file
        The scan-to-file job service scans one or more documents and
        stores the result in one or more (1) local files, (2) files
        in a distributed file system or (3) files in a document
        repository, depending on the prescriptive instructions submitted
        with the job service request."
    ::= { xcmJobServiceTypesOID 1 }




XCMI Working Group                File 40jobtc                 [Page 36]

XCMI Job Monitoring TC v5.10                           18 September 2002

xcmJobServiceScanToPrintOID OBJECT-IDENTITY
    STATUS     current
    DESCRIPTION
        "Scan-to-print
        The scan-to-print job service scans one or more documents and
        prints the results on a local printer or on a network
        printer, depending on the prescriptive instructions submitted
        with the job service request."
    REFERENCE
        "See:   'xcmJobServiceCopyOID' below"
    ::= { xcmJobServiceTypesOID 2 }

xcmJobServiceScanToFaxOID OBJECT-IDENTITY
    STATUS     current
    DESCRIPTION
        "Scan-to-fax
        The scan-to-fax job service scans one or more documents and
        faxes the results using a local fax or on a network
        fax, depending on the prescriptive instructions submitted
        with the job service request."
    ::= { xcmJobServiceTypesOID 3 }

xcmJobServiceScanToMailListOID OBJECT-IDENTITY
    STATUS     current
    DESCRIPTION
        "Scan-to-mail-list
        The scan-to-mail-list job service scans one or more documents
        and distributes the results using the distribution list
        specified by the prescriptive instructions submitted
        with the job service request."
    ::= { xcmJobServiceTypesOID 4 }

xcmJobServiceFaxToFileOID OBJECT-IDENTITY
    STATUS     current
    DESCRIPTION
        "Fax-to-file
        The fax-to-file job service accepts one or more documents via
        inbound fax and stores the result in one or more: (1) local
        files, (2) files in a distributed file system or (3) files in a
        document repository, depending on the prescriptive instructions
        submitted with the job service request."
    ::= { xcmJobServiceTypesOID 5 }

xcmJobServiceFaxToPrintOID OBJECT-IDENTITY
    STATUS     current
    DESCRIPTION
        "Fax-to-print
        The fax-to-print job service accepts one or more documents via
        inbound fax and prints the results on a local printer or on a
        network printer, depending on the prescriptive instructions
        submitted with the job service request."
    ::= { xcmJobServiceTypesOID 6 }



XCMI Working Group                File 40jobtc                 [Page 37]

XCMI Job Monitoring TC v5.10                           18 September 2002

xcmJobServiceFaxToMailListOID OBJECT-IDENTITY
    STATUS     current
    DESCRIPTION
        "Fax-to-mail-list
        The fax-to-mail-list job service accepts one or more documents
        via inbound fax and distributes the results using the
        distribution list specified by the prescriptive instructions
        submitted with the job service request."
    ::= { xcmJobServiceTypesOID 7 }

xcmJobServicePrintOID OBJECT-IDENTITY
    STATUS     current
    DESCRIPTION
        "Print
        The print job service accepts one or more documents submitted
        with the job print service request, referenced from the job
        request in a distributed file system or document repository
        and prints on a network printer, depending on the prescriptive
        instructions submitted with the job service request."
    ::= { xcmJobServiceTypesOID 8 }

xcmJobServiceFileToFaxOID OBJECT-IDENTITY
    STATUS     current
    DESCRIPTION
        "File-to-fax
        The file-to-fax job service accepts one or more documents
        submitted with the job print service request, referenced from
        the job request in a distributed file system or document
        repository and faxes the results using a local fax or on a
        network fax, depending on the prescriptive instructions
        submitted with the job service request."
    ::= { xcmJobServiceTypesOID 9 }

xcmJobServiceFileToMailListOID OBJECT-IDENTITY
    STATUS     current
    DESCRIPTION
        "File-to-mail-list
        The file-to-mail-list job service accepts one or more documents
        submitted with the job service request, referenced from the job
        request in a distributed file system or document repository
        and distributes the results using the distribution
        list specified by the prescriptive instructions submitted
        with the job service request.  The file-to-mail-list service
        permits a user to compose a compound job whose sub-job produces
        a file, such as a scan-to-file, and whose subsequent sub-jobs
        use the file as input, such as a sub-job to file-to-mail-list
        and a second (parallel) sub-job to print from the same file."
    ::= { xcmJobServiceTypesOID 10 }







XCMI Working Group                File 40jobtc                 [Page 38]

XCMI Job Monitoring TC v5.10                           18 September 2002

xcmJobServiceCopyOID OBJECT-IDENTITY
    STATUS     current
    DESCRIPTION
        "Copy
        The copy job service reads images (via xerography, scanner,
        etc.) and writes (prints) those images (with a pipeline delay of
        zero or more images) on a local marker sub-unit (copy service
        need NOT write a disk or other secondary storage file of the
        copy images).  Compare with 'xcmJobServiceScanToPrint' (strictly
        used for digital scanners - scan to print service shall ALWAYS
        write a disk or other secondary storage file of the whole
        document, i.e., the set of copy images).

        The key distinction, from an Image Processing point of is that,
        for a copy (or local copy) job the IIT (input - scan) and IOT
        (output - marker) are WELL-TUNED with respect to each other to
        produce the best quality and the best performance.

        Whereas for ScantoPrint the target IOT (or the its capabilities)
        are not assumed to be known at the time scanning and in order to
        achieve best quality, there is often an additional  step of
        image processing that the systems needs to go through (often
        called Image Interoperability Services).

        Usage:  A copy job service shall ALWAYS expose
        an 'xcmHrDeviceCopier' (scanner and marker are invisible)
        in the IETF HR MIB, XCMI HRX MIB, and XCMI Job Monitoring MIB.

        Usage:  A scan to print job service shall ALWAYS expose
        an 'xcmHrDeviceScanner' and an 'hrDevicePrinter' (marker)
        in the IETF HR MIB, XCMI HRX MIB, and XCMI Job Monitoring MIB."
    REFERENCE
        "See:   'xcmJobServiceScanToPrintOID' above"
    ::= { xcmJobServiceTypesOID 11 }

xcmJobServiceFileToFileOID OBJECT-IDENTITY
    STATUS     current
    DESCRIPTION
        "File-to-file
        The file-to-file job service accepts one or more documents
        submitted with the job print service request, referenced from
        the job request in a distributed file system or document
        repository and stores the result in one or more: (1) local
        files, (2) files in a distributed file system or (3) files in a
        document repository, depending on the prescriptive instructions
        submitted with the job service request.
        The initial intent of this job service is support the transfer
        of a file to a device's hard drive.  When the file transfer is
        complete, the file-to-file job is complete.  It is expected that
        a user will eventually process the file from the device hard
        drive, but that action starts a new job.  This service might be
        used in the processing of a secure-print action."
    ::= { xcmJobServiceTypesOID 12 }


XCMI Working Group                File 40jobtc                 [Page 39]

XCMI Job Monitoring TC v5.10                           18 September 2002


XcmJMJobState ::= TEXTUAL-CONVENTION
    STATUS     current
    DESCRIPTION
        "A job may be in any of the states defined by this textual-
         convention.

        The Xerox Job model is a refinement of the ISO DPA standard and
        generalizes to non-printing devices.  The textual definitions
        given here are an abbreviation of the full specification of the
        semantics of the job states given in the Xerox Job Model
        specification.  Agent implementers of this MIB need to refer to
        the Xerox Job Model specification in addition to this textual
        convention.

        Traps shall be generated when a job performs a job
        state transition.  In order to reduce network traffic, it is
        recommended, but not required, that an implementation suppress
        traps for self-loops.  The xcmJobPreviousState can be used to
        detect self-loops and suppress self-loop traps by not sending
        traps when the value of the xcmJobPreviousState is the same as
        the value of the xcmJobCurrentState.

        When a job is in the processing state,
        the state of the assigned device(s) is needed to fully
        represent the state of the job.  In addition, the
        job-state-reasons attributes provides additional, more abstract,
        user feedback about what is happening to the job when the job
        is in many of its states.  See the Xerox Job Model
        Specification, Phase 1 or later for the specification of which
        job-state-reasons values may be used with which job states..

        ISO DPA:   Job-current-state
        Standard values are defined for the current-job-state and
        previous-job-state attributes of the DPA job object, as follows:

        unknown           The job state is not known, or is
                          indeterminate, or is not returned by the
                          operation.  (id-val-job-state-unknown)

        creating          The job has been created on the server by
                          the create-job sub-operation of the Submit
                          request, but a Submit request with neither (1)
                          a TRUE value for the job-submission-complete
                          component of the SubmitArgument nor (2) a TRUE
                          value for the job-process-before-completely-
                          specified (long jobs) job attribute has not
                          yet been received and no document has started
                          processing.  The job maybe in the process
                          of being checked by the server for
                          attributes, defaults being applied, a
                          device being selected, etc.
                          [Renamed from ISO DPA pre-processing state,
                          but kept the same enum code, since the

XCMI Working Group                File 40jobtc                 [Page 40]

XCMI Job Monitoring TC v5.10                           18 September 2002

                          semantics are identical.] (id-val-job-
                          state-pre-processing)

NOTE: The Xerox Job Model transitory state: evaluate-hold shall not be
visible to requesters, and therefore is not in the Job Monitoring MIB.

        held              The job is waiting to be released for
                          scheduling for any number of reasons as
                          specified by the value of the job's job-
                          state-reasons attribute.  (id-val-job-
                          state-held)

                          See the Xerox Job Model Specification, Phase 1
                          or later for the specification of which
                          job-state-reasons values may be used when the
                          job is in the held state.

        pending           The job is
                          waiting to start processing on a device and
                          has no shared system resources assigned to it
                          yet.  (id-val-job-state-pending)

[The ISO DPA processing and printing states have been combined into a
single job state, called processing, which includes any device activity,
so that the job life cycle can be used for all kinds of jobs, not just
printing jobs, and have the same life cycle.  The printing state is
DEPRECATED. In addition, the difference between the ISO DPA processing
state and printing state was one of user feed back only.  The standard
specified no differences in job state transitions between the processing
and printing states.  Therefore, ISO DPA should have used the device-
state-of-devices-assigned mechanism to provide the user feedback
distinction between the processing and printing states.  In fact,
neither Novell's NDPS nor IBM's PSM DPA products implement the printing
state, only the processing state.  Only Printxchange implements the
printing state (as well as the processing state).  So we will propose to
ISO DPA that the DPA printing state be deprecated.

[For convenience in understanding the difference between ISO DPA and the
Job Monitoring MIB (and the Xerox Job Model), the ISO DPA processing and
printing specifications are given here first, followed by the new
(Xerox) definition of processing which incorporates the semantics of the
ISO DPA processing and printing states, and extends these semantics to
sub-jobs.]

[ISO DPA processing specification:  The server is processing the job, or
has made the job ready for printing, but the output device is not yet
printing it, either because the job hasn't reached the output device or
because the job is queued in the output device or some other spooler,
awaiting the output device to print it.]

[ISO DPA printing state specification which is DEPRECATED by the Job
Monitoring MIB:  The server has completed processing the job and the
output device is currently printing the job on at least one printer.
That is, a print engine is either printing pages of the job, or failing

XCMI Working Group                File 40jobtc                 [Page 41]

XCMI Job Monitoring TC v5.10                           18 September 2002

in its attempt to print pages of the job because of some wait state,
such as, start-wait, end-wait, needs-attention, etc.  The complete job
state includes the detailed status represented in the printers' printer-
state attribute(s).]

[The following Xerox definition of the 'processing' job state combines
the ISO DPA processing and printing states into a single state, called
'processing', which can be used with any kind of device:
        processing        The server is:
                          (1) processing the job, or
                          (2) has made the job ready for processing, but
                          the device is not yet processing it, either:
                            (a) because the job hasn't reached the
                                device or
                            (b) because the job is queued in the device
                                or some other spooler, awaiting the
                                device to process it
                          or
                          (3) has completed processing the job and the
                          device is currently processing (printing,
                          scanning, sending-fax, receiving-fax,
                          sending-e-mail, filing, or retrieving) the job
                          on at least one device. That is, a device is
                          either performing input-output of the job, or
                          failing in its attempt to perform input-output
                          of the job because of some wait state, such
                          as, start-wait, end-wait, needs-attention,
                          etc.

                          Additional information about the job's current
                          state is also given in the job's
                          job-state-reasons attribute for when the job
                          is in any of its states, including processing.
                          See the Xerox Job Model for which values of
                          the job's job-state-reasons attribute may be
                          used when the job is in the processing state.

                          NOTE: DPA does not yet have any
                          job-state-reasons defined for the
                          processing/printing states.
                          (id-val-job-state-processing)]

        paused            The job has been paused as a result of a
                          PauseJob request.

                          NOTE: The Xerox Job Model has renamed the
                          PauseJob and ResumeJob operations to HoldJob
                          and ReleaseJob and has changed the semantics
                          to put the job back into the held state,
                          with the job-hold attribute set to TRUE
                          and the job-hold-set value added to the
                          job-state-reasons attribute instead of putting
                          into the paused state.  So the paused state
                          remains only for use with ISO DPA systems that

XCMI Working Group                File 40jobtc                 [Page 42]

XCMI Job Monitoring TC v5.10                           18 September 2002

                          have implemented the paused state.
                          (id-val-job-state-paused)

        interrupted       The job was interrupted by the InterruptJob
                          request for an intervening job, and shall
                          resume processing automatically once the
                          intervening job has completed.  The
                          interrupted job may relinquish shared
                          resources and devices to the interrupting job,
                          but not to other jobs.
                          (id-val-job-state-interrupted)

        terminating       The job has been cancelled by a CancelJob
                          request or aborted by the server and is in
                          the process of terminating.  The job's job-
                          state-reasons attribute contains the
                          reasons that the job is being terminated.
                          (id-val-job-state-terminating)

        retained          The job is being retained at the server as
                          a result of the job's job-retention-period
                          being non-zero. The job has (1) completed
                          successfully or with warnings or errors,
                          (2) been aborted while [processing] printing
                          by the server, or (3) been cancelled by the
                          CancelJob request before or during
                          processing.  The job's job-state-reasons
                          attribute contains the reasons that the job
                          has been retained.

                          While in the retained state, all of the
                          job's document data (and resources, if any)
                          shall be retained by the server; thus a job
                          in the retained state [could be resubmitted
                          using the Resubmit request in ISO DPA
                          Part 3.].  ResubmitJob shall create a new job
                          object instance and assign a new
                          job-identifier.  See the Xerox Job Model spec.
                          (id-val-job-state-retained)

        completed         The job has either:
                              (1) completed successfully or with
                                  warnings or errors,
                              (2) been aborted by the server while
                                  processing, or
                              (3) been cancelled by the CancelJob
                                  request,
                            AND the job's:
                              (1) job-retention-period was zero or
                                  has expired, or
                              (2) job-discard-time has arrived.
                          OR a ResubmitJob operation has been issued
                             which forces the old job to the completed
                             state and makes a new job object instance

XCMI Working Group                File 40jobtc                 [Page 43]

XCMI Job Monitoring TC v5.10                           18 September 2002

                             with a new job identifier.  See the Xerox
                             Job Model specification.

                          The job's job-state-reasons attribute
                          contains the reason(s) that the job has
                          been completed.

                          While in the completed state, a job's
                          document data (and resources if any) need
                          not be retained by the server; thus a job
                          in the completed state could not be
                          resubmitted. The length of time that a job
                          may be in this state, before transitioning
                          to unknown, is implementation-dependent.
                          However, servers that implement the
                          completed job-state shall retain, as a
                          minimum, the following attributes for any
                          job in the completed state: job-identifier,
                          job-owner, job-name, current-job-state,
                          devices-assigned, and job-state-reasons, plus
                          as a Xerox extension, the accounting
                          attributes:
                          xcmJobAccountingUserName,
                          xcmJobAccountingInformation,
                          xcmJobStartedProcessingTime,
                          xcmJobImpressionsCompleted,
                          xcmJobMediaSheetsCompleted,
                          xcmJobCompletionTime, xcmJobWorkUnitType
                          XcmHrDevTrafficUnit,
                          and xcmJobUnitsOfWorkCompleted
                          so that an accounting management application
                          can copy the accounting data from the MIB
                          before the job is deleted from the MIB.
                          Jobs that have been moved to the OPTIONAL
                          'Job History' device SHALL be in the
                          'completed' state (or 'aborted' or 'canceled'
                          states with the PWG Job Mon MIB).
                          (id-val-job-state-completed)

                This is a type 2 enum."
    SYNTAX     INTEGER {
                   other(1),
                   unknown(2),       -- the following enum values are +2
                                     -- of the final arc of the ISO DPA
                                     -- id-val-job-state-xxx OID
                   created(3),       -- renamed from ISO DPA
                                     -- pre-processing - same semantics
                   pending(6),
                   processing(7),    -- redefined to include
                                     -- printing. See description.
                   interrupted(8),
                   retained(11),
                   held(12),
                   paused(13),       -- only for monitoring ISO DPA

XCMI Working Group                File 40jobtc                 [Page 44]

XCMI Job Monitoring TC v5.10                           18 September 2002

                                     -- systems that have the paused
                                     -- state.  Other systems should use
                                     -- the held state.
                   terminating(14),
                   completed(17),
                   printing(18)      -- DEPRECATED - use processing(7)
               }

XcmJMJobStateReasons ::= TEXTUAL-CONVENTION
    STATUS     current
    DESCRIPTION
        "This representation is bit-encoded, so that multiple reasons
        can occur at once.  Each bit corresponds to an ISO DPA OID for
        the same reason.  The MIB enum value is given by:

                value = 2 ** (last arc of DPA id-val-reasons-xxx OID -1)
                id-val-reasons-documents-needed = 1.0.10175.1.6.19.1

        See the Xerox Job Model Specification, Phase 1 or later for the
        specification of which job-state-reasons values may be used with
        which job states.

        ISO DPA:   Job-state-reasons
        This attribute identifies the reason or reasons that the job is
        in the held, [processing,] terminating, retained, or completed
        state.  The server shall indicate the particular reason(s) by
        setting the value of the job-state-reasons attribute.  When the
        job is not in any of these states, the server shall set the
        value of the job-state-reasons attribute to the empty set.

        The following standard values are defined:

        jobIncoming                       0x1
            The job has been accepted by the server or device, but the
            server or device is expecting (1) additional operations from
            the client to finish creating the job and/or (2) is
            accessing/accepting document data.

            NOTE - this reason has been renamed from the ISO DPA
            'documents-needed' to the IPP 'job-incoming' which has been
            generalized to include the condition before the job has been
            closed by the client.  (id-val-reasons-documents-needed)

        jobHoldSet                        0x2
            The value of the job's job-hold attribute is TRUE.  (id-val-
            reasons-job-hold-set)

        jobProcessAfterSpecified          0x4
            The value of the job's job-process-after attribute has
            specified a time specification that has not yet occurred.
            Renamed from ISO DPA job-print-after-specified.  (id-val-
            reasons-job-process-after-specified)

        requiredResourcesNotReady         0x8

XCMI Working Group                File 40jobtc                 [Page 45]

XCMI Job Monitoring TC v5.10                           18 September 2002

            At least one of the resources needed by the job, such as
            media, fonts, resource objects, etc., is not ready on any of
            the physical device's for which the job is a candidate.
            (id-val-reasons-required-resources-not-ready)

        successfulCompletion              0x10
            The job completed successfully.  (id-val-reasons-successful
            completion)

        completedWithWarnings             0x20
            The job completed with warnings.  (id-val-reasons-completed-
            with-warnings)

        completedWithErrors               0x40
            The job completed with errors (and possibly warnings too).
            (id-val-reasons-completed-with-errors)

        cancelledByUser                   0x80
            The job was cancelled by the user using the CancelJob
            request.  (id-val-reasons-cancelled-by-user)

        cancelledByOperator               0x100
            The job was cancelled by the operator using the CancelJob
            request.  (id-val-reasons-cancelled-by-operator)

        abortedBySystem                   0x200
            The job was aborted by the system.  (id-val-reasons-aborted-
            by-system)

        logfilePending                    0x400
            The job's logfile is pending file transfer.  (id-val-
            reasons-logfile-pending)

        logfileTransferring               0x800
            The job's logfile is being transferred.  (id-val-reasons-
            logfile-transferring)

        The following bits are from IPP (and start at the high end of
        the bits definitions):

        jobOutgoing                       0x40000000
            Configuration 2 only:  The server is transmitting the job to
            the device.

        The remaining bits are reserved for future standardization and
        shall not be used by conforming implementations.

This is the equivalent of a type 2 enum."
    SYNTAX      INTEGER(0..2147483647)  -- 31 bits, all but sign bit






XCMI Working Group                File 40jobtc                 [Page 46]

XCMI Job Monitoring TC v5.10                           18 September 2002

XcmJMJobXStateReasons ::= TEXTUAL-CONVENTION
    STATUS     current
    DESCRIPTION
        "This representation is bit-encoded, so that multiple reasons
        can occur at once.  Each bit corresponds to a Xerox OID for
        the same Xerox extension to the ISO DPA job state reason.
        In a DPA protocol, the DPA and Xerox OID can be intermixed.
        But in a bit encoded SNMP information object, we need to
        keep the bit encodings separate.
        The MIB enum value is given by:

            value = 2 ** (last arc of Xerox xid-val-reasons-xxx OID)
            xid-val-reasons-cascaded = 1.2.840.113550.1.6.19.0
            The last arc is shown in parens in the description.

        ISO DPA:   Job-state-reasons
        This attribute identifies the reason or reasons that the job is
        in the held, [processing] terminating,
        retained, or completed state.  The server shall indicate the
        particular reason(s) by setting the value of the
        job-state-reasons [xcmJobStateReasons, xcmJobXStateReasons,
        and xcmX2StateReasons objects] attribute.  When the job is not
        in any of these states, the server shall set the value of the
        job-state-reasons attribute to the empty set.

        The following values are defined as Xerox extensions.  The
        specification is copied from the Xerox Job Model, Phase 1,
        updated to version 0.67, 12/20/96.

        NOTE: In the Xerox Job Model, the acronym JSP stands for Job
        Service Provider.  In ISO DPA and this MIB the term server is
        used equivalently to JSP.

        The extensions defined by Printxchange:

        cascaded                          0x1
            (0) After the outbound gateway retrieves all job and
            document attributes and data, it stores the information into
            a spool directory.  Once it has done this, it sends the
            supervisor a job-processing event with this job-state-reason
            which tells the supervisor to transition to a new job state.

        deletedByAdministrator            0x2
            (1) The administrator has issued a Delete operation on the
            job or a Clean operation on the server or queue containing
            the job; therefore the job may have been cancelled before or
            during processing, and will have no retention-period or
            completion-period.

        discardTimeArrived                0x4
            (2) The job has been deleted (cancelled with the job-
            retention-period set to 0) due to the fact that the time
            specified by the job's job-discard-time has arrived [if the
            job had already completed, the only action that would have

XCMI Working Group                File 40jobtc                 [Page 47]

XCMI Job Monitoring TC v5.10                           18 September 2002

            occurred is that the job-retention-period would be set to 0
            and the job is deleted].

        postprintFailed                   0x8
            (3) The post-processing agent failed while trying to log
            accounting attributes for the job; therefore the job has
            been placed into retained state for a system-defined period
            of time (Printxchange, 5 minutes), so the administrator can
            examine it, resubmit it, etc.  The post-processing agent is
            a plug-and-play mechanism which the system and the customer
            uses to add functionality that is executed after a job has
            finished processing.

        submissionInterrupted             0x10
            (4) Indicates that the job was not completely submitted for
            the following reasons: (1) the server has crashed before the
            job was closed by the client.  The server shall put the job
            into the completed state (and shall not process the job).
            (2) the server or the document transfer method has crashed
            in some non-recoverable way before the document data was
            entirely transferred to the server.  The server shall put
            the job into the completed state (and shall not process the
            job). (3) the client crashed or failed to close the job
            before the time-out period (Printxchange, 20 minutes). The
            server shall close the job and put the job into the held
            state with job-state-reasons of submission-interrupted and
            job-hold-set and with the job's job-hold attribute set to
            TRUE.  The user may release the job for scheduling by
            issuing the ReleaseJob operation.

        maxJobFaultCountExceeded          0x20
            (5) The job has been faulted and returned by the server
            several times and that the job-fault-count exceeded the
            device's (or server's, if not defined for the device) cfg-
            max-job-fault-count.  The job is automatically put into the
            held state regardless of the hold-jobs-interrupted-by-
            device-failure attribute. This job-state-reasons value is
            used in conjunction with the job-interrupted-by-device-
            failure value.

        Job timed-out while processing (optional):

        Implementation option:  The following values of job-state-
        reasons are derived from ISO DPA printer states for use when the
        system moves a processing job to the held state because a site-
        settable time-out condition was exceeded while the job was in
        the processing state:

        devicesNeedAttentionTimeOut       0x40
            (6) One or more document transforms that the job is using
            needs human intervention in order for the job to make
            progress, but the human intervention did not occur within
            the site-settable time-out value and the JSP has
            transitioned the job to the held state.

XCMI Working Group                File 40jobtc                 [Page 48]

XCMI Job Monitoring TC v5.10                           18 September 2002


        needsKeyOperatorTimeOut           0x80
            (7) One or more devices or document transforms that the job
            is using need a specially trained operator (who may need a
            key to unlock the device and gain access) in order for the
            job to make progress, but the key operator intervention did
            not occur within the site-settable time-out value and the
            JSP has transitioned the job to the held state.

        jobStartWaitTimeOut               0x100
            (8) The JSP has stopped the job at the beginning of
            processing to await human action, such as installing a
            special cartridge or special non-standard media, but the job
            was not resumed within the site-settable time-out value and
            the JSP has transitioned the job to the held state.
            Normally, the job is resumed by means outside the job model,
            such as some local function on the device.

        jobEndWaitTimeOut                 0x200
            (9) The JSP has stopped the job at the end of processing to
            await human action, such as removing a special cartridge or
            restoring standard media, but the job was not resumed within
            the site-settable time-out value and the JSP has
            transitioned the job to the retained state.  Normally, the
            job is resumed by means outside the job model, such as some
            local function on the device, whereupon the job shall
            transition immediately to the terminating state.

        jobPasswordWaitTimeOut            0x400
            DEPRECATED: (10) The JSP has stopped the job at the
            beginning of processing to await input of the job's
            password, but the human intervention did not occur within
            the site-settable time-out value and the JSP has
            transitioned the job to the held state.  Normally, the
            password is input and the job is resumed by means outside
            the job model, such as some local function on the device.

            This value is DEPRECATED because the JSP shall move Secure
            Jobs from processing to held when they are the next to run
            and set the jobPasswordWait job-state-reason, so that the
            device is not blocked.

        deviceTimedOut                    0x800
            (11) A device that the job was using has not responded in a
            period specified by the device's site-settable device-
            timeout-period attribute (In ISO DPA the printer's printer-
            timeout-period attribute).

        connectingToDeviceTimeOut         0x1000
            (12) The JSP is attempting to connect to one or more devices
            which may be dial-up, polled, or queued, and so may be busy
            with traffic from other systems, but JSP was unable to
            connect to the device within the site-settable time-out
            value and the JSP has transitioned the job to the held state

XCMI Working Group                File 40jobtc                 [Page 49]

XCMI Job Monitoring TC v5.10                           18 September 2002


        Reasons used when the job is in processing state:

        The following values for the job-state-reasons attribute have
        been added by the Job Model team to give requesters feedback
        about the job when the job is in the processing state:

        transferring                      0x2000
            (13) The job is being transferred to a down stream server or
            device.

        queueInDevice                     0x4000
            (14) The job has been queued in a down stream server or
            device.

        jobCleanup                        0x8000
            (15) The JSP is performing cleanup activity as part of
            ending normal processing.

        processingToStopPoint             0x10000
            (16) The requester has issued an InterruptJob operation and
            the JSP is processing up until the specified stop point
            occurs.

        Other reasons added by the Xerox Job Model:

        The following values for the job's job-state-reasons attribute
        have been added by the Xerox Job Model team:

        jobPasswordWait                   0x20000
            (17) Either:
            (1) The JSP has selected the Secure Job to be next to
            process, but instead of assigning resources and starting the
            job processing, the JSP has transitioned the job to the held
            state to await entry of a password (and dispatched another
            job, if there is one) OR
            (2) the JSP has interpreted (ripped) the Secure Job and the
            marker is scheduled separately, so that the JSP transitions
            the job to the held state to await entry of a password (and
            dispatched another job, if there is one).

            The user resumes the job either locally or by issuing a
            ReleaseJob supplying a job-password=secret-code input
            parameter that SHALL match the job's job-password attribute.

        validating                        0x40000
            (18) The job is validating the job after a CreateJob
            operation.  The job state may be creating, held, pending, or
            processing.

        queueHeld                         0x80000
            (19) The operator has held the entire queue by means outside
            the scope of the Job model.


XCMI Working Group                File 40jobtc                 [Page 50]

XCMI Job Monitoring TC v5.10                           18 September 2002


        jobProofWait                      0x100000
            (20) The job has produced a single proof copy and is in the
            held state waiting for the requester to issue the ReleaseJob
            operation to release the job to print normally, obeying the
            job-copies and copy-count job and document attributes that
            were originally submitted.

        heldForDiagnostics                0x200000
            (21) The system is running intrusive diagnostics, so the all
            jobs are being held.

        serviceOffLine                    0x400000
            (22) The service/document transform is off-line and
            accepting no jobs.  All pending jobs are put into the held
            state.  This could be true if its input is impaired or
            broken.

        noSpaceOnServer                   0x800000
            (23) The job is held because there is no room on the server
            to store all of the job.  For example, there is no room for
            the document data or a scan-to-file job.

        pinRequired                       0x1000000
            (24) The device requires that a pin be entered in order to
            proceed, because the PIN was not supplied with the document
            or job.

        exceededAccountLimit              0x2000000
            (25) The account for which this job is drawn has exceeded
            its limit.  This condition should be detected before the job
            is scheduled so that the user does not wait until his/her
            job is scheduled only to find that the account is overdrawn.
            This condition may also occur while the job is processing
            either as processing begins or part way through processing.

            An overdraft mechanism should be included to be user-
            friendly, so as to minimize the chances that the job cannot
            finish or that media is wasted.  For example, the JSP should
            finish the current copy for a job with collated document
            copies, rather than stopping in the middle of the current
            document copy.

        jobHeldForRetry                   0x4000000
            (26) The job encountered some errors that the JSP could not
            recover from with its normal retry procedures, but the error
            is worth trying the job later, such as phone number busy or
            remote file system in-accessible.  For such a situation, the
            JSP shall add the held-for-retry value to the job's job-
            state-reasons attribute and transition the job from the
            processing to the held (via the evaluate-hold internal
            momentary state), rather than to the retained state.

        The remaining bits are reserved for future standardization and

XCMI Working Group                File 40jobtc                 [Page 51]

XCMI Job Monitoring TC v5.10                           18 September 2002

        shall not be used by conforming implementations.

        This is the equivalent of a type 2 enum."
    SYNTAX      INTEGER(0..2147483647)  -- 31 bits, all but sign bit

XcmJMJobX2StateReasons ::= TEXTUAL-CONVENTION
    STATUS     current
    DESCRIPTION
        "This representation is bit-encoded, so that multiple reasons
        can occur at once.  Each bit corresponds to a Xerox OID for
        the same Xerox extension to the ISO DPA job state reason.
        In a DPA protocol, the DPA and Xerox OID can be intermixed.
        But in a bit encoded SNMP information object, we need to
        keep the bit encodings separate.  XcmJMJobX2StateReasons
        provides an additional 31 bits for Xerox extensions in addition
        to the 31 bits provided for by XcmJMJobXStateReasons.
        The MIB enum value is given by:

            value = 2 ** (last arc of Xerox xid-val-reasons-xxx OID -30)
            xid-val-reasons-xxx = 1.2.840.113550.1.6.19.30

        jobPrinting                       0x1

        (30) At least one of the output device to which the job is
            assigned is marking media. This value is useful for servers
            and output devices which spend a great deal of time
            processing (1) when no marking is happening and then want to
            show that marking is now happening or (2) when the job is in
            the process of being canceled or aborted while the job
            remains in the 'processing' state, but the marking has not
            yet stopped so that impression or sheet counts are still
            increasing for the job.

            This job-state-reason value is defined in the PWG Job
            Monitoring MIB and IPP.  It has been generalized here for
            jobs that use more than one device.

            This job-state-reason value should be used instead of the
            'printing' which has been deprecated in this MIB (and is
            recommended against in ISO DPA in a corrigenda).

        jobInterpreting                   0x2
            (31) The job is interpreting document data.

            This job-state-reason value is defined in the PWG Job
            Monitoring MIB and IPP.  It has been generalized here for
            jobs that use more than one device and for devices that can
            be interpreting more than one job at a time.

        jobScanning                       0x4
            (32) At least one of the input devices to which the job is
            assigned is scanning document data.

        jobFaxReceiving                   0x8

XCMI Working Group                File 40jobtc                 [Page 52]

XCMI Job Monitoring TC v5.10                           18 September 2002

            (33) At least one of the FAX devices to which the job is
            assigned is receiving FAX document data.

        jobFaxSending                     0x10
            (34) At least one of the FAX devices to which the job is
            assigned is sending FAX document data.

        jobFileReceiving                  0x20
            (35) The job is receiving files or document data.

        jobFileSending                    0x40
            (36) The job is sending files or document data.

        jobMailReceiving                  0x80
            (37) The job is receiving electronic mail document data.

        jobMailSending                    0x100
            (38) The job is sending electronic mail document data.

            value = 2 ** (30 - last arc of PSIS pid-val-reasons-xxx OID)
            pid-val-reasons-cancelled-by-shutdown =
                1.2.826.0.1050.8.1.6.19.0

        NOTE: the Xerox extensions to DPA work from right to left and
        X/Open PSIS extensions work from left to right, avoiding the
        sign bit.

        The remaining bits (in the middle) are reserved for future
        standardization and shall not be used by conforming
        implementations.

        The following PSIS bits are defined using the PSIS extensions to
        ISO DPA starting with the left-most bit, not counting the sign
        bit.  These definitions are taken from the August 28, 1995,
        version 5.0 of the X/Open PSIS specification.  [Text in brackets
        indicates additions and clarifications made for the Job
        Monitoring MIB.]

        cancelledByShutdown               0x40000000
            the job was cancelled because the server or device was
            shutdown before completing the job.  The job shall be placed
            in the pending state [if the job was not started, else the
            job shall be placed in the terminating state].

        deviceUnavailable                 0x20000000
            This job was aborted by the system because the device is
            currently unable to accept jobs.  This reason [shall be]
            used in conjunction with the reason aborted-by-system. The
            job shall be placed in the pending state.

        wrongDevice                        0x10000000
            This job was aborted by the system because the device is
            unable to handle this particular job; the spooler should try
            another device.  This reason [shall be] used in conjunction

XCMI Working Group                File 40jobtc                 [Page 53]

XCMI Job Monitoring TC v5.10                           18 September 2002

            with the reason aborted-by-system.  The job shall be pending
            if the queue contains other physical devices that the job
            could process on, and the spooler is capable of not sending
            the job back to a physical device that has rejected the job
            for this job-state-reasons value.  Otherwise, [the job]
            shall be retained.

        badJob                            0x8000000
            This job was aborted by the system because this job has a
            major problem[, such as an ill-formed PDL]; the spooler
            should not even try another printer.  This reason [shall be]
            used in conjunction with the reason aborted-by-system. The
            job shall be placed in the [terminating] state.

        jobInterruptedByDeviceFailure     0x4000000
            The device or supervisor failed while the job was
            [processing/]printing.  The spooler is keeping the job in
            the held state until an operator can determine what to do
            with the job.

        This is the equivalent of a type 2 enum."
    SYNTAX      INTEGER(0..2147483647)  -- 31 bits, all but sign bit

XcmJMDocType ::= TEXTUAL-CONVENTION
    STATUS     current
    DESCRIPTION
        "Jobs contain contained-documents.  Contained-documents may be
        printable, font, or resource objects.  This had
        been deleted due to object deletions from 41jobmon.mib, but
        has been restored along with those objects.

        ISO DPA:   Document-type
        The following standard values are defined:

        printable    Specifies that this document is to be printed on
                     the assigned printer.  (id-val-document-type-
                     printable)

        font         Specifies that this document is a font resource
                     which may be required by one or more of the
                     printable documents associated with the print-
                     job.  See the font object class.  (id-val-
                     document-type-font)

        resource     Specifies that this document contains resource
                     data, of some type other than font, which may be
                     required to print one or more of the printable
                     documents associated with the print-job.  See
                     the resource object class.  (id-val-document-
                     type-resource)

        This is a type 2 enum."
    SYNTAX     INTEGER {
                   other(1),

XCMI Working Group                File 40jobtc                 [Page 54]

XCMI Job Monitoring TC v5.10                           18 September 2002

                   unknown(2),
                   printable(3),    -- the following enum values are +3
                   font(4),         -- of the final arc of the ISO DPA
                   resource(5)      -- id-val-document-type-xxx OID
               }

XcmJMDocFileNameType ::= TEXTUAL-CONVENTION
    STATUS     current
    DESCRIPTION
        "The type of file name syntax from which a document is
        obtained for an output job, such as print, or for which a
        document is produced for an input job, such as scan-
        to-file.  The file name syntax types are taken from ISO DPA
        for the DistinguishedNameStringSyntax data type.  This had
        been deleted due to object deletions from 41jobmon.mib, but
        has been restored along with those objects.

        ISO DPA:   distinguished-name-syntax
        The following standard values are defined:

        automatic   server recognizes the syntax
        X-500       ISO 9594 Directory Service
        XFN         X/OPEN Federated Names
        DCE         Distributed Computing Environment
                    includes X.500 and CDS
        CDS         Cell Directory Service - part of DCE
        NIS         Network Information Service
        DNS         Domain Name Service
        DEC-NS      Digital Name Service
        Internet-mail Internet Mail address
        XNS         Xerox Network System
        Bindery     Bindery
                    example: FILE_SERVER_NAME\OBJECT_NAME
        NDS         Novell Directory Service
                    example: .objectName.container.organization or
                    .cn=objectName.ou=container.o=organization
        URL         HTTP Universal Resource Locator
                    examples:
                    http://www.organization-name.org/homepage.htm
                    ftp://ftp-out.external.hp.com/snmpmib/dpa/dpa-00.doc
        POSIX       POSIX file name (ISO 9945-1)  -- file name types
        UNIX        UNIX(TM) file name
        OS/2        OS/2 file name
        PC-DOS      PC DOS file name
        NT          NT file name
        MVS         MVS file name
        VM          VM file name
        OS/400      OS/400 file name
        VMS         VMS file name
        UNC         Microsoft Universal Name Convention
                    example:
                    \\fileservername\volume\filepath\filename.ext
        NetWare     NetWare file path name
                    example: servername\volume\filepath\filename.ext

XCMI Working Group                File 40jobtc                 [Page 55]

XCMI Job Monitoring TC v5.10                           18 September 2002


        This is a type 2 enum."
    SYNTAX     INTEGER {
                   other(1),
                   unknown(2),
    -- the following enum values are +3 of the final arc of the
    -- ISO DPA id-val-dn-syntax-xxx OID
                   fntAutomatic(3),
                   fntX500(4),
                   fntXFN(5),
                   fntDCE(6),
                   fntCDS(7),
                   fntNIS(8),
                   fntDNS(9),
                   fntDECNS(10),
                   fntInternetMail(11),
                   fntXNS(12),
                   fntBindery(13),
                   fntNDS(14),        -- has been added to ISO DPA
                   fntURL(15),        -- has been added to ISO DPA
                   fntPOSIX(23),    -- file name types
                   fntUNIX(24),
                   fntOS2(25),
                   fntPCDOS(26),
                   fntNT(27),
                   fntMVS(28),
                   fntVM(29),
                   fntOS400(30),
                   fntVMS(31),
                   fntUNC(32),        -- has been added to ISO DPA
                   fntNetWare(33)     -- has been added to ISO DPA
               }

XcmJMDocState ::= TEXTUAL-CONVENTION
    STATUS     current
    DESCRIPTION
        "The following standard values are defined for the state of
        contained-documents:

        transferPending
            The server has created the document object, but the data
            transfer of the document data has not started or completed
            (id-val-document-state-transfer-pending)

        pending
            The server has received the document data and the document
            is waiting for processing to begin.  The job may already be
            in the processing state, if the job's job-scheduling
            attribute is not after-complete (see the current-job-state
            and job-scheduling job attributes.  (id-val-document-state-
            pending)

        processing
            The server has started processing this document, or has made

XCMI Working Group                File 40jobtc                 [Page 56]

XCMI Job Monitoring TC v5.10                           18 September 2002

            the document ready for processing by a device, but the
            device is not yet processing it, either because the document
            hasn't reached the device or because the document is queued
            in the device or some other spooler, awaiting the device to
            process it, or the device has finished processingthe
            document and some additional processing is needed, such as
            image processing after scanning.  (id-val-document-state-
            processing)

        printing
            The server has completed processing the document and the
            output device is currently printing the document on at least
            one printer. That is, a print engine is either printing
            pages of the document, or failing in its attempt to print
            pages of the document because of some wait state, such as,
            start-wait, end-wait, needs-attention, etc.  The complete
            document state includes the detailed status represented in
            the devices' device-state attribute(s).

        NOTE: Other job-service-type-specific states will be added in
        the future, such as scanning.

        completed
            The server has completed this document.  The job may still
            be in the processing state, or may be in the retained state.
            The job shall move to the retained state when all documents
            are completed (id-val-document-state-completed)

        This is a type 2 enum."
    SYNTAX     INTEGER {
                   other(1),
                   unknown(2),
     -- the following enum values are +3 of the final arc of the
     -- ISO DPA id-val-document-state-xxx OID
                   transferPending(3),
                   pending(4),
                   processing(5),
                   completed(6),
                   printing(7)
               }

XcmJMDocOutputMethod ::= TEXTUAL-CONVENTION
    STATUS     current
    DESCRIPTION
        "This object is bit coded, so that multiple document output
        requests may be made for the document.  Each bit corresponds to
        one of the ISO DPA output OIDs.

        ISO DPA:   Output
        This attribute identifies the output processing for the media
        on which the document is to be printed.

        The following standard values are defined.  The value of the
        bit is given by the formula:

XCMI Working Group                File 40jobtc                 [Page 57]

XCMI Job Monitoring TC v5.10                           18 September 2002


           bit value = 2 ** (last OID arc)
           id-val-output-page-collate = 1.0.10175.1.6.115.0

        pageCollate                       0x1
            This value specifies that the pages of a document are to be
            in sequence, when multiple copies of the document are
            specified by the copy-count attribute (possibly up to some
            implementation-defined maximum number of copies). Whether
            this effect is achieved by placing copies of the document in
            multiple output bins or in the same output bin with
            implementation-defined document separation is
            implementation-dependent. Also whether it is achieved by
            making multiple passes over the document or by using an
            output sorter is implementation-dependent.

            Either pageCollate or noPageCollate shall be set, but not
            both.  If both pageCollate and noPageCollate are set, the
            noPageCollate value shall be ignored.  (id-val-output-page-
            collate)

        noPageCollate                     0x2
            This value specifies that the copies of the pages of a
            document are to follow one another when multiple copies are
            specified by the copy-count attribute. That is, if 3 copies
            are specified, three copies of page 1 are printed then three
            copies of page 2, etc., and no collating of these pages is
            desired. This may be useful in some implementations where
            multiple copies requires re-interpretation of the document
            format and the document contains some compute intensive
            pages (such as images)  (id-val-output-no page-collate)

        decollate                         0x10
            The parts of a multi-part form are to be separated and
            sorted into stacks for each part.

        Either decollate or noDecollate shall be set, but not both.  If
        both decollate and noDecollate are set, the noDecollate value
        shall be ignored.  (id-val-output-decollate)

        noDecollate                       0x20
            The parts of a multi-part form are to remain intact  (id-
            val-output-no decollate)

        burst                             0x40
            Continuous media is to be separated into individual sheets,
            generally by bursting along perforations.

        Either burst or noBurst shall be set, but not both.  If both
        burst and noBurst are set, the noBurst value shall be ignored.
        (id-val-output-burst)

        noBurst                           0x80
            Continuous media is to remain continuous, no bursting is

XCMI Working Group                File 40jobtc                 [Page 58]

XCMI Job Monitoring TC v5.10                           18 September 2002

            desired  (id-val-output-no burst)

        stackingDefault                   0x400
            A site-defined output-stacking operation is to be applied
            (id-val-output-stacking-default)

        This is the equivalent of a type 2 enum."
    SYNTAX    INTEGER(0..65535)

XcmJMGroupSupport ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION
        "The terse conformance statement of ALL mandatory, conditionally
        mandatory, and optional XCMI Job Monitoring MIB groups
        supported by this management agent implementation (i.e.,
        version) on this host system, specified in a bit-mask.

        The current set of values (which may be extended in the future)
        is given below:

              1 : xcmJMBaseGroup                   -- 2**0   conditional
              2 : xcmJMJobGenBasicGroup            -- 2**1   conditional
              4 : xcmJMDevicesAssignedGroup        -- 2**2   deprecated
              8 : xcmJMClientIdMapGroup            -- 2**3   optional
             32 : xcmJMJobGenExtGroup              -- 2**5   conditional
            128 : xcmJMDocGenBasicGroup            -- 2**7   conditional
            256 : xcmJMDocPrintExtGroup            -- 2**8   conditional
            512 : xcmJMJobGenSpoolingBasicGroup    -- 2**9   conditional
           1024 : xcmJMJobGenSpoolingExtGroup      -- 2**10  conditional
           2048 : xcmJMJobGenAccountingBasicGroup  -- 2**11  conditional
           4096 : xcmJMMediaConsumedGroup          -- 2**12  conditional
           8192 : xcmJMColorImpsConsumedGroup      -- 2**13  conditional
          16384 : xcmJMJobAlertGroup               -- 2**14  conditional
          32768 : xcmJMDocAlertGroup               -- 2**15  conditional
          65536 : xcmJMJobImpsByMediumSizeGroup    -- 2**16  conditional

        Note: The following had been deprecated, but have been made
        current starting with version 4.00: xcmJMJobGenExtGroup,
        xcmJMJobGenSpoolingBasicGroup, xcmJMJobGenAccountingBasicGroup,
        xcmJMMediaConsumedGroup, and xcmJMJobImpsByMediumSizeGroup.
        The following had been deleted, but are restored as of version
        4.01: xcmJMDocGenBasicGroup, xcmJMDocPrintExtGroup,
        xcmJMJobGenSpoolingExtGroup, xcmJMColorImpsConsumedGroup,
        and xcmJMDocAlertGroup.
        The following were deleted in v2.51:
        xcmJMJobStateMsgGroup and xcmJMJobTreeBasicGroup.

        Usage:  Conforming management agents shall ALWAYS accurately
        report their support for XCMI Job Monitoring MIB groups."
    SYNTAX        INTEGER(0..2147483647)  -- biggest int = 2**31-1





XCMI Working Group                File 40jobtc                 [Page 59]

XCMI Job Monitoring TC v5.10                           18 September 2002

XcmJMImpsCountType ::= TEXTUAL-CONVENTION
    STATUS      current                -- was deprecated, current in v4
    DESCRIPTION "
        The recognized impression counting types for impressions
        produced by the jobs.
        The following standard values are defined for the count-type.

        total count
                Count all impressions.
        black and white count
                Count impressions requiring only black colorant.
        highlight color count
                Count impressions requiring black plus one other
                colorant.
        full color count
                Count impressions requiring 3 or more colorants.
        one visible color count
                Count impressions for which one visible color is
                printed.  This is determined when a printer driver
                converts a document to PDL formatted data.  This is
                related in a specific accounting method rather than
                consumed colorants.  The differentiation between a
                'one visible color' impression from an impression of
                another type is device dependent, i.e., a device might
                consider 'one visible', 'black and white', and
                'highlight' to be three different types.
        limited visible color count
                Count impressions for which multiple visible colors are
                printed, but when the impression should not be
                considered 'full color'.  This is determined when a
                printer driver converts a document to PDL formatted
                data.  This is related in a specific accounting method
                rather than consumed colorants.  The choice of a number
                of colors that differentiates a 'limited color'
                impression from a 'full color' (or other type of)
                impression is device dependent.
        one colorant count
               Count impressions on which any one colorant is used,
                whether black or any other color.
        two colorant count
                Count impressions on which any two colorants are used,
                whether or not black is used.
        three colorant count
                Count impressions on which any three colorants are
                used, whether or not black is used.
        four colorant count
                Count impressions on which any four colorants are used,
                whether or not black is used.

     NOTE: Other count-type may be added in the future according to
           the requirements of accounting services."
    SYNTAX INTEGER {
                other(1),
                totalCount(4),

XCMI Working Group                File 40jobtc                 [Page 60]

XCMI Job Monitoring TC v5.10                           18 September 2002

                blackAndWhiteCount(5),
                highlightColorCount(6),
                fullColorCount(7),
                oneVisibleColorCount(11),
                limitedVisibleColorCount(19),
                oneColorantCount(21),
                twoColorantCount(22),
                threeColorantCount(23),
                fourColorantCount(24)
                }

XcmJMMediumType ::= TEXTUAL-CONVENTION
    STATUS     current             -- was deprecated, current in v4
    DESCRIPTION
        "The recognized types of media.

        NOTE: For this MIB, these values are enums, instead of
        strings.  This departure from the IETF Printer MIB where
        medium-types are strings is so that the medium types can be more
        easily localized.  Also the xcmJMMediaConsumedGroup accounting
        group also has the media names as string values so that
        accounting systems can use either the enum type or the medium
        name.

        ISO DPA:   Medium-type
        This attribute identifies the type of this medium. (e.g.
        stationery, envelope, transparency, etc.)

        The following standard values are defined:

        stationery
            Separately cut sheets of an opaque material  (id-val-medium-
            type-stationery)Sometimes called 'standard'.

        transparency
            Separately cut sheets of a transparent material  (id-val-
            medium-type-transparency)

        envelope
            Envelopes that can be used for conventional mailing purposes
            (id-val-medium-type-envelope)

        envelopePlain
            Envelopes that are not pre-printed and have no windows  (id-
            val-medium-type-envelope-plain)

        envelopeWindow
            Envelopes that have windows for addressing purposes  (id-
            val-medium-type-envelope-window)

        continuousLong
            Continuously connected sheets of an opaque material
            connected along the long edge  (id-val-medium-type-
            continuous-long)

XCMI Working Group                File 40jobtc                 [Page 61]

XCMI Job Monitoring TC v5.10                           18 September 2002


        continuousShort
            Continuously connected sheets of an opaque material
            connected along the short edge  (id-val-medium-type-
            continuous-short)

        tabStock
            Media with tabs  (id-val-medium-type-tab)

        multiPartForm
            Form medium composed of multiple layers not pre-attached to
            one another;  each sheet may be drawn separately from an
            input source  (id-val-medium-multi-part-form)

        labels
            Label-stock  (id-val-medium-labels)

        multiLayer
            Form medium composed of multiple layers which are pre-
            attached to one another, e.g. for use with impact printers
            (id-val-medium-type-multi-layer).

        The following are additional types that are being proposed to
        ISO DPA and so continue with the same enum and OID assignments:

        prePrinted
            pre-printed medium, other than letterhead

        letterhead
            pre-printed letterhead

        coverStock
            cover medium

        The following are additional types that are orthogonal to media-
        type and so will not be proposed to ISO DPA as additional media-
        type.  Instead, these will be proposed as separate attributes of
        the medium object.

        Therefore, they will be assigned as Xerox extension bits for use
        in the Job Monitoring MIB:

        drilled
            Medium with holes. (Corresponds to the existing ISO DPA
            medium-holes attribute)

        coated
            Medium with some coating. (Will be proposed to ISO DPA as a
            separate medium object attribute, possibly Boolean).

        recycled
            recycled medium.  (Will be proposed to ISO DPA as a separate
            medium object attribute, possibly Boolean).


XCMI Working Group                File 40jobtc                 [Page 62]

XCMI Job Monitoring TC v5.10                           18 September 2002


        heavyWeight
            heavy-weight medium.  (Corresponds to the existing ISO DPA
            medium-weight attribute).

        This is a type 2 enum."
    SYNTAX     INTEGER {
                   other(1),
                   unknown(2),
    -- the following enum values are +3 of the final arc of the
    -- ISO DPA id-val-medium-type-xxx OID
                   stationery(3),       -- sometimes called "standard"
                   transparency(4),
                   envelope(5),         -- any kind of envelope
                   envelopePlain(6),    -- no window
                   continuousLong(7),
                   continuousShort(8),
                   tabStock(9),
                   multiPartForm(10),
                   labels(11),
                   envelopeWindow(12),  -- see envelope-plain(3)
                   multiLayer(13),
                   prePrinted(14),
                   letterhead(15),
                   coverStock(16),

    -- the following are Xerox extensions that will not be proposed to
    -- ISO DPA as medium-types, since DPA either has or should have
    -- additional medium attributes to represent these:
                   drilled(100),
                   coated(101),
                   recycled(102),
                   heavyWeight(103)
               }

--
--          Job Monitoring MIB Extensions TC Dummy Group (DO NOT USE)
--
--          DO NOT USE - Present to suppress compiler warnings ONLY!
--
--          Note:  The following objects have 'odd' use of case in their
--          names (i.e., 'xCm...'), in order to make obvious their
--          related textual conventions

xCmJobMonTCDummy     OBJECT IDENTIFIER ::= { xcmJobMonTC 999 }

xCmJobMonTCJobServiceTypeOID OBJECT-TYPE
    SYNTAX      XcmJMJobServiceTypeOID
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmJobMonTCDummy 1 }

xCmJobMonTCJobState OBJECT-TYPE

XCMI Working Group                File 40jobtc                 [Page 63]

XCMI Job Monitoring TC v5.10                           18 September 2002

    SYNTAX      XcmJMJobState
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmJobMonTCDummy 2 }

xCmJobMonTCJobStateReasons OBJECT-TYPE
    SYNTAX      XcmJMJobStateReasons
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmJobMonTCDummy 3 }

xCmJobMonTCJobXStateReasons OBJECT-TYPE
    SYNTAX      XcmJMJobXStateReasons
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmJobMonTCDummy 4 }

xCmJobMonTCJobX2StateReasons OBJECT-TYPE
    SYNTAX      XcmJMJobX2StateReasons
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmJobMonTCDummy 5 }

xCmJobMonTCDocType OBJECT-TYPE
    SYNTAX      XcmJMDocType
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmJobMonTCDummy 6 }

xCmJobMonTCDocFileNameType OBJECT-TYPE
    SYNTAX      XcmJMDocFileNameType
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmJobMonTCDummy 7 }

xCmJobMonTCDocState OBJECT-TYPE
    SYNTAX      XcmJMDocState
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmJobMonTCDummy 8 }

xCmJobMonTCDocOutputMethod OBJECT-TYPE
    SYNTAX      XcmJMDocOutputMethod
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmJobMonTCDummy 9 }

XCMI Working Group                File 40jobtc                 [Page 64]

XCMI Job Monitoring TC v5.10                           18 September 2002


xCmJobMonTCGroupSupport OBJECT-TYPE
    SYNTAX      XcmJMGroupSupport
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmJobMonTCDummy 10 }

xCmJobMonTCImpsCountType OBJECT-TYPE
    SYNTAX      XcmJMImpsCountType
    MAX-ACCESS  not-accessible
    STATUS      current                -- was deprecated, current in v4
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmJobMonTCDummy 11 }

xCmJobMonTCMediumType OBJECT-TYPE
    SYNTAX      XcmJMMediumType
    MAX-ACCESS  not-accessible
    STATUS      current                -- was deprecated, current in v4
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmJobMonTCDummy 12 }

END
































XCMI Working Group                File 40jobtc                 [Page 65]

XCMI Job Monitoring TC v5.10                           18 September 2002



10.  REFERENCES

[JMP]  PWG Job Monitoring MIB, version 1.0, February 6, 1998:
       ftp://ftp.ietf.org/internet-drafts/
             ietf-printmib-job-monitor-07.txt
       ftp://ftp.pwg.org/pub/pwg/jmp/internet-drafts/
             ietf-printmib-job-monitor-07.txt
--
--
       Version 1.0 will be published as an IETF Informational RFC in
       the near future.

[MAP}  Job Submission Protocol Mapping Recommendations
       for the Job Monitoring MIB, Version 1.0, February 10, 1998
       ftp://ftp.ietf.org/internet-drafts/
             ietf-printmib-job-protomap-03.txt
--
--
       Version 1.0 will be published as an IETF Informational RFC in
       the near future.
textual-conventions and explanation] 



XCMI Working Group                File 40jobtc                 [Page 84]

XCMI Job Monitoring TC v5.10                           18 September 2002
                           TABLE OF CONTENTS                            

1.  INTRODUCTION ...............................................       2
2.  OVERVIEW OF THE JOB MONITORING MIB .........................       4
  2.1.  The Multi-function Job Model ...........................       4
3.  GOALS FOR THE JOB MONITORING MIB (HISTORICAL) ..............       6
  3.1.  Job Management not in the Job Monitoring MIB ...........       8
  3.2.  Submission to the Printer Working Group (PWG) ..........       8
4.  USAGE CONFIGURATIONS OF SYSTEMS OF THE JOB MONITORING MIB ..       9
  4.1.  Configuration 1 - client-printer .......................       9
  4.2.  Configuration 2 - client-server-printer ................      10
  4.3.  Configuration 3 - client-spooler-supervisor-printer ....      11
5.  CONVENTIONS ................................................      13
  5.1.  Object Naming ..........................................      13
  5.2.  Terminology ............................................      14
6.  DESCRIPTION OF THE JOB MONITORING MIB ......................      15
  6.1.  Events .................................................      15
  6.2.  Text Attributes ........................................      15
  6.3.  The Job Information table & Document Information table .      16
  6.4.  Logical and physical printers ..........................      17
  6.5.  Overview of the Job Monitoring MIB groups and tables ...      18
  6.6.  Minimal Implementation: only 17 accessible objects .....      20
7.  CONFORMANCE REQUIREMENTS AND IMPLEMENTERS GUIDE ............      22
  7.1.  Conformance req'ts for agents in devices & servers .....      22
    7.1.1.  Use of Registered PWG attributes ...................      26
  7.2.  XCMI Job Monitoring MIB conformance requirements .......      27
  7.3.  Client conformance requirements ........................      28
  7.4.  Hints to improve Client performance with SNMPv1 ........      31
  7.5.  The OPTIONAL "Completed Job History" device ............      32
8.  JOB MONITORING MIB TEXTUAL CONVENTIONS .....................      33
9.  MANAGED OBJECT DEFINITIONS .................................      35
  9.1.  Definition of JM Textual Conventions ...................      35
    9.1.1.  XcmJMJobServiceTypeOID .............................      36
    9.1.2.  xcmJobServiceTypesOID ..............................      36
    9.1.3.  xcmJobServiceScanToFileOID .........................      36
    9.1.4.  xcmJobServiceScanToPrintOID ........................      37
    9.1.5.  xcmJobServiceScanToFaxOID ..........................      37
    9.1.6.  xcmJobServiceScanToMailListOID .....................      37
    9.1.7.  xcmJobServiceFaxToFileOID  .........................      37
    9.1.8.  xcmJobServiceFaxToPrintOID .........................      37
    9.1.9.  xcmJobServiceFaxToMailListOID ......................      38
    9.1.10.  xcmJobServicePrintOID .............................      38
    9.1.11.  xcmJobServiceFileToFaxOID .........................      38
    9.1.12.  xcmJobServiceFileToMailListOID ....................      38
    9.1.13.  xcmJobServiceCopyOID ..............................      39
    9.1.14.  xcmJobServiceFileToFileOID ........................      39
    9.1.15.  XcmJMJobState .....................................      40
    9.1.16.  XcmJMJobStateReasons ..............................      45
    9.1.17.  XcmJMJobXStateReasons .............................      47
    9.1.18.  XcmJMJobX2StateReasons ............................      52
    9.1.19.  XcmJMDocType ......................................      54
    9.1.20.  XcmJMDocFileNameType ..............................      55
    9.1.21.  XcmJMDocState .....................................      56
    9.1.22.  XcmJMDocOutputMethod ..............................      57
    9.1.23.  XcmJMGroupSupport .................................      59

XCMI Working Group                 File 40jobtc                 [Page i]

XCMI Job Monitoring TC v5.10                           18 September 2002
                           TABLE OF CONTENTS                            

    9.1.24.  XcmJMImpsCountType ................................      60
    9.1.25.  XcmJMMediumType ...................................      61
    9.1.26.  JobMon MIB Extensions TC Dummy Group (DO NOT USE) .      63
10.  REFERENCES ................................................      66
11.  CHANGE LOG ................................................      67

















































XCMI Working Group                File 40jobtc                 [Page ii]
